" over a prepared statement. Each wrapper has the prepared statement ID, the SQL string and the prepared state- ment itself. This allows a prepared statement to support transactions. Working with vectors of such wrappers allows any particular connection to have more than one prepared statement. Prepared statements are created only when a request is made using a fetch method. This avoids performance degradation problems in Oracle databases, since preparing all prepared statements in advance would degrade performance.4 In addition, prepared statements can be cached to enhance performance. The number of prepared statements maintained in the cache is configurable. Caching ensures that only some prepared statements are prepared over the connections while the rest are prepared only on an as-needed basis. A statement represents an SQL query. Unlike a prepared statement, a statement is compiled and executed whenever it is used. Every statement applies over all connec- tions, just as with prepared statements. The caching mechanism is also supported for statements and the cache size is configurable. An instance of the ConnectionPool class is created to perform any database oper- ation. This instance can be accessed to store any object in the database. Remote applications which need to access ConnectionPool must explicitly create an instance of it. Connection pooling is supported in both transaction and non-transaction mode. The ConnectionPool class has a single method, and that is to get a connection. In the transaction mode, a connection is granted when a transaction begins. Connection pooling in the transaction mode can lock and unlock connections at the appropriate times when a transaction is started and completed over a connec- tion. Connection pooling will also lock the connection based on the thread involved in the transaction. In particular, multiple threads involved in transaction processing might request connections, wherein the connection must be allocated/de-allocated for each transaction based on availability o