DB2 10.5 for Linux, UNIX, and Windows
DB2 10.5 for Linux, UNIX, and Windows
This parameter indicates if a fenced mode process is kept after a fenced mode routine call is complete. Fenced mode processes are created as separate system entities in order to isolate user-written fenced mode code from the database manager agent process. This parameter is only applicable on database servers.
If keepfenced is set to No, and the routine being executed is not threadsafe, a new fenced mode process is created and destroyed for each fenced mode invocation. If keepfenced is set to no, and the routine being executed is threadsafe, the fenced mode process persists, but the thread created for the call is terminated. If keepfenced is set to yes, a fenced mode process or thread is reused for subsequent fenced mode calls. When the database manager is stopped, all outstanding fenced mode processes and threads will be terminated.
Setting this parameter to yes will result in additional system resources being consumed by the database manager for each fenced mode process that is activated, up to the value contained in the fenced_pool parameter. A new process is only created when no existing fenced mode process is available to process a subsequent fenced routine invocation. This parameter is ignored if fenced_pool is set to 0.
Recommendation: In an environment in which the number of fenced mode requests is large relative to the number of non-fenced mode requests, and system resources are not constrained, then this parameter can be set to yes. This will improve the fenced mode process performance by avoiding the initial fenced mode process creation processing time since an existing fenced mode process will be used to process the call. In particular, for Java™ routines, this will save the cost of starting the Java Virtual Machine (JVM), a very significant performance improvement.
For example, in an OLTP debit-credit banking transaction application, the code to perform each transaction could be performed in a stored procedure which executes in a fenced mode process. In this application, the main workload is performed out of fenced mode processes. If this parameter is set to no, each transaction incurs the additional processing time of creating a new fenced mode process, resulting in a significant performance reduction. If, however, this parameter is set to yes, each transaction would try to use an existing fenced mode process, which would avoid this additional processing time.
In previous versions of DB2®, this parameter was known as keepdari.