f connections. 44 This performance degradation is a result of "open cursor" problems. 11 Configuration Management In non-transaction mode, there is no concept of connection locking. However, prepared statements are locked when used in order to avoid conflicts which would arise from two applications simultaneously using the same prepared statement. Owing to this locking, it is important that an application does not hold a prepared statement for a long time. This is done using a configurable prepared statement timeout. When a prepared statement is requested from the RDBMS resource pool in trans- action mode, it is ascertained whether it is being called by a thread that is itself still in transaction mode. If so, then the connection pooling returns only the prepared statement that was prepared in the same connection as that used in the transaction. If a request for a prepared statement comes from a thread which is not in the trans- action mode, then the RDBMS resource pool returns the respective prepared state- ment from any one of the non-transactional connections where the prepared statement is free. If none are free, then the RDBMS resource pool waits until one is returned. The prepared statement is returned either by the application once the operation is complete or it is automatically returned to the pool on timeout. It is important that a statement requested from a thread involved in a transaction returns the statement from the same connection that is used in the transaction. 11.2.11.4 Module Services and Communication Services User-written modules can be written and started as a separate thread from the same JVM as the server. This feature allows the user to write their own server modules and plug them into the server framework. User-written server modules can use the framework API and provide useful management information to the user-written clients. There is communication both on the server side (between the BE and FE servers) and on the client side (between the FE servers and the Java Client). This communi