Application Server threaded access to a JCA connection in ...€¦ · Introduction. The IBM WebSphere Application Server connection pool helps to alleviate connection ... Understanding

© Copyright IBM Corporation 2012 TrademarksUnderstanding connection transitions: Avoiding multi-threadedaccess to a JCA connection in WebSphere Application Server

Page 1 of 17

Understanding connection transitions: Avoiding multi-threaded access to a JCA connection in WebSphereApplication ServerAnoop Ramachandra ([email protected])Senior Staff Software EngineerIBM

Rispna Jain ([email protected])Software Deployment ManagerIBM

09 May 2012

IBM® WebSphere® Application Server JCA connection manager provides connectionpooling and enables administrators to establish a pool of connections that can be shared byapplications running on an application server. However, the sharing of a JCA connection acrossmultiple threads by an application can result in various exceptions. This article describes someof the application coding practices that lead to connection sharing across multiple threads, andexplains the multi-threaded detection capabilities provided by WebSphere Application Server.

IntroductionThe IBM WebSphere Application Server connection pool helps to alleviate connectionmanagement overhead as well as decrease development tasks for data access. With WebSphereApplication Server connection pooling, most user requests do not incur the overhead of creatinga new connection because the data source can locate and use an existing connection from thepool of connections. The WebSphere Application Server connection manager supports bothunshareable and shareable connections and manages the state of connection objects between thefree pool and shared/unshared pool. It also provides local transaction containment (LTC) in anunspecified transaction context.

To use connections effectively and to avoid any multi-threaded access to a connection in anapplication, it is important to understand connection transitions between the free pool and shared/unshared pool with respect to transactions. These concepts are described in detail in this article.

Connection sharing terminologyA connection handle is a representation of a physical connection and is not the physicalconnection to the back end resource manager. A connection handle is returned by the connectionmanager when the getConnection() method is invoked from an application.

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/developerworks/ibm/trademarks/

mailto:[email protected]

mailto:[email protected]

developerWorks® ibm.com/developerWorks/

Understanding connection transitions: Avoiding multi-threadedaccess to a JCA connection in WebSphere Application Server

Page 2 of 17

An unshareable connection cannot be shared with other components in an application. Thecomponent using this connection has full control over it. Access to a resource marked asunshareable means that there is a one-to-one relationship between the connection handle that acomponent is using and the physical connection with which the handle is associated. This accessimplies that every call to the getConnection() method returns a connection handle solely for therequesting user.

The use of a shareable connection means that, if conditions allow it, different getConnection()requests by an application will actually receive a handle for the same physical connection tothe resource. The physical connection is shared through multiple connection handles insteadof retrieving a new physical connection from the connection pool for every getConnection()invocation.

Factors that determine sharing include:

• each getConnection() request should have the same connection properties.• each getConnection() request should be made within the same sharing scope.

Connection sharing conditions are such that a connection can be shared only within a sharingscope. The most common sharing scope is a transaction scope where multiple active connectionhandles can share the same physical connection. There are two transaction scopes in WebSphereApplication Server:

• Global transaction• Local transaction containment (LTC)

Within an LTC boundary, there cannot be multiple active connection handles that use the samephysical connection. However, the physical connection can be reused if the previous connectionhandle that wraps the same physical connection is closed.

Connection reuse occurs when this pattern is used:

Get connection 1 -> use connection 1 -> commit/rollback connection 1 (optional) -> closeconnection 1 -> get connection 2 -> use connection 2 -> commit/rollback connection 2(optional) -> close connection 2 ->...

Connection transition

The conditions causing the transition of a connection from the shared/unshared pool to free poolare illustrated in Figure 1; Table 1 explains the terms shown in the figure. The conditions are:

• When an application invokes close() method on a connection in the unshared pool, theconnection is returned to the free pool, if "AutoCommit" is set to true and there are no otherreferences to the connection held by the application or Connection Manager.

• When an application invokes close() method on a connection in the shared pool and theLTC or global transaction is still active, the connection is not returned to the free pool.

ibm.com/developerWorks/ developerWorks®


Page 3 of 17

The connection remains in the shared pool and can be reused within the transaction. Theconnection is returned to the free pool when the LTC or global transaction ends.

Figure 1. Transitions of a connection between different pools when close()method is invoked on a connection object

Table 1. Terminology description for Figure 1

Terminology Description

Shared Pool Pool holding currently used shared connections.

Unshared Pool Pool holding currently used unshared connections.

Free Pool Pool holding available free connections.

Close() Application invokes close() method on the connection object.

Local Transaction Containment (LTC) Application which operates outside of a global transaction acquires adefault context in WebSphere Application Server called LTC.

Global Transaction (GT) A global transaction context might be created automatically forEJB methods by using container managed transaction support andspecifying an appropriate transaction attribute for the method. The JavaTransaction API (JTA) UserTransaction interface can also be used tocreate a global transaction context from within a servlet, a messagedriven bean, or an EJB component that specifies the use of beanmanaged transactions. Within a global transaction, multiple resourcemanagers can be accessed and the transaction manager will coordinateamong all the resource managers to ensure the atomicity of updates.

Table 2 explains the state of a connection when an application invokes the close() method onconnection object, releasing a connection to free pool.

Table 2. Conditions to release a connection to free pool

Connection type AutoCommit LTC (Local TransactionContainment)

GT (Global Transaction) Transition



Page 4 of 17

Shared True True False Connection does notreturn to the free pool.The sharing scope is thetransaction and until theLTC ends, the connectionwill not be returned to thefree pool.

False True False Changing the Autocommitvalue will not affectthe release of sharedconnection from sharedpool to free pool. Onlywhen transaction endsthe shared connection isreturned to the free pool.

True/False False True Within a global transaction,the database ignoresthe Autocommit setting.Transaction Manager takescare of commit or rollbackas per application call, andonce the transaction endsthe connection is returnedback to the free pool.

Unshared True True False Connection is returned tothe free pool immediately.

False True False If Autocommit is set tofalse, then the connectioncannot be returned back tothe free pool. Applicationhas to invoke commiton connection objectexplicitly prior to closingthe connection. This wouldreturn the connection backto free pool.

True/False False True Connections are returnedback to the free pool whenthe connection is closedand global transactionends. The Autocommitsetting is ignored.

Multi-threaded access to a connectionMulti-threaded access to a connection occurs when an application shares a connection handleacross multiple threads before closing it. This condition should be avoided, as it can lead tovarious unexpected failures during the execution of the application.

This section describes some scenarios that could lead to multi-threaded access to a connection.These scenarios have been recreated with WebSphere Application Server V7.0 and V8.0 usingand IBM DB2 database.

Scenario 1: Multiple threads sharing a single connectionThe code in Listing 1 creates a connection object at class scope and then shares the samedatabase connection object across multiple threads. Each thread creates a statement using theconnection object, executes the statement and then closes the connection.



Page 5 of 17

Listing 1. Scenario 1: Multiple threads sharing a single connectionimport java.sql.*;import javax.naming.*;import javax.sql.*;public class Test extends Thread{ static Connection conn = null ; static DataSource ds = null;

public static void main (String args []) { try{ Context initialContext = new InitialContext(); ds = (DataSource)initialContext.lookup("java:comp/env/test"); //get connection from datasource conn = ds.getConnection(); }catch (Exception e) { // handle exception e.printStackTrace(); } int NUM = 5; // create multiple threads Thread[] multithread = new Thread[NUM]; // spawn threads for (int i = 0; i < NUM; i++) { multithread[i] = new Test(); multithread[i].start(); } }

public void run() { // Create a Statement try{ Statement stmt = conn.createStatement (); ResultSet rs = stmt.executeQuery ("select * from EMPLOYEE"); stmt.close(); rs.close(); conn.close(); }catch (Exception e){ //handle exception e.printStackTrace(); } }}

In this scenario, when one thread closes the connection, the other threads operating on the sameconnection will be affected. This could result in the exception shown in Listing 2.

Exception description (Listing 2): Attempted to perform an operation on a Statement object that isalready closed. Retrieve a new instance of the Statement object on which to perform the operation.

Listing 2. Scenario 1: Exceptioncom.ibm.db2.jcc.am.SqlException: [jcc][10120][10943][3.63.75] Invalid operation:statement is closed. ERRORCODE=-4470, SQLSTATE=null at com.ibm.db2.jcc.am.fd.a(fd.java:663) at com.ibm.db2.jcc.am.fd.a(fd.java:60) at com.ibm.db2.jcc.am.fd.a(fd.java:103) at com.ibm.db2.jcc.am.yn.wb(yn.java:4177) at com.ibm.db2.jcc.am.yn.a(yn.java:1695) at com.ibm.db2.jcc.am.yn.getMoreResults(yn.java:1095) at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement

The exception shown in Listing 3 could also be thrown.



Page 6 of 17

Exception description (Listing 3): Attempted to perform an operation on a Connection objectthat is already closed. Retrieve a new instance of the Connection object on which to perform theoperation.

Listing 3. Scenario 1: Exceptioncom.ibm.websphere.ce.cm.ObjectClosedException: DSRA9110E: Connection is closed.at com.ibm.ws.rsadapter.jdbc.WSJdbcWrapper.createClosedException(WSJdbcWrapper.java:114)[4/22/12 2:10:18:825 CDT] 00000079 SystemErr R atcom.ibm.ws.rsadapter.jdbc.WSJdbcConnection.runtimeXIfNotClosed(WSJdbcConnection.java:3427)[4/22/12 2:10:18:825 CDT] 00000079 SystemErr R atcom.ibm.ws.rsadapter.jdbc.WSJdbcConnection.createStatement(WSJdbcConnection.java:1684)[4/22/12 2:10:18:825 CDT] 00000079 SystemErr R atcom.ibm.ws.rsadapter.jdbc.WSJdbcConnection.createStatement(WSJdbcConnection.java:1634)

Scenario 2: Application passing connection handleApplication code should not pass a cached connection handle from one instance of a data accessclient to another client instance. Transferring the connection handle between client instancescreates the problematic contingency of one instance using a connection handle that is referencedby another.

For example, when the application code of a client instance that receives a transferred handlecloses the handle and the client instance that retains the original reference to the handle tries toreclaim it, the application server issues an exception.

Listings 4 and 5 shown some exceptions expected in this case.

Exception description (Listing 4): An exception was detected cleaning up the ManagedConnectionfor a destroy operation. Refer to the error reported by the database software to help determine thecause of the error.

Listing 4. Scenario 2: Exception0000004d WSRdbManagedC W DSRA0180W: Exception detected duringManagedConnection.destroy(). The exception is:com.ibm.ws.exception.WsException: DSRA0080E: An exception was received by the Data Store Adapter Invalid operation: Connection is closed. ERRORCODE=-4470, SQLSTATE=08003. With SQL State: 08003 SQL Code : -4470

Exception description (Listing 5): An exception was detected while closing JDBC Connection whichwas already closed.

Listing 5. Scenario 2: Exceptionjava.lang.IndexOutOfBoundsException: Index: 1, Size: 0at java.util.ArrayList.RangeCheck(ArrayList.java:572)at java.util.ArrayList.get(ArrayList.java:347)at com.ibm.ws.rsadapter.jdbc.WSJdbcObject.closeChildWrappers(WSJdbcObject.java:222)at com.ibm.ws.rsadapter.jdbc.WSJdbcObject.close(WSJdbcObject.java:184)

Scenario 3: Closing connections in finalize methodIf an application closes the connection handle in the finalize() method, then the garbage collectionthread might run and try to close the connection at the same time as the connection manager



Page 7 of 17

cleanup, resulting in unexpected behavior. Listing 6 illustrates the invocation of the close() methodon a connection object within the finalize() method.

Listing 6. Scenario 3: Closing connections in finalize method

public void example { Connection Conn=null; // other methods

protected void finalize() throws Throwable { conn.close(); }

There could also be a problem if a JDBC object is not closed by the thread that is using the object.An example of such a scenario is when a reference to this JDBC object is stored in a differentobject and the reference is closed by a finalize() method during garbage collection.

The exception that could be thrown here is shown in Listing 7.

Exception description (Listing 7): The connection manager caught an exception while trying toperform an operation on a ManagedConnection.

Listing 7. Scenario 3: Exception

MCWrapper E J2CA0081E:Method cleanup failed while trying to execute method cleanup onManagedConnection WSRdbManagedConnectionImpl@7dd47dd4 from resource <resource name>

Scenario 4: SQLj applications must close SQLj connection context

The IBM implementations of JDBC and SQLJ provide a number of application programminginterfaces, properties, and commands for developing JDBC and SQLJ applications. (SeeResources for more about SQLJ.) Not closing the SQLJ connection context will result in thefinalize method of the SQLJ connection context object being run by the garbage collector.Part of the SQLJ connection context finalize method is to close the SQLJ connection contextunderlying objects (for example, prepared statements, connections, profiles, and so on). Thefact that the closure happens by the garbage collector on the finalizer thread, results in violationof the WebSphere Application Server programming model as multiple threads access the sameWebSphere Application Server JDBC object (the normal thread, and the finalizer thread). This isshown in Figure 2.



Page 8 of 17

Figure 2. Multithreaded access to connection object

The code in Listing 8 illustrates this scenario.

Listing 8. Scenario 4: SQLj applications must close SQLj connection conteximport java.sql.*;import javax.naming.*;import javax.sql.*;

#sql context CtxSqlj; // Create connection context class CtxSqljContext ctx=new InitialContext();DataSource ds=(DataSource)ctx.lookup("jdbc/sampledb");Connection con=ds.getConnection();String empname; // Declare a host variable

con.setAutoCommit(false); // Do not autocommitCtxSqlj myConnCtx=new CtxSqlj(con); // Create connection context object myConnCtx#sql [myConnCtx] {SELECT LASTNAME INTO :empname FROM EMPLOYEE WHERE EMPNO='000010'}; // Use myConnCtx for executing an SQL statement

myconnCtx,close(KEEP_CONNECTION);

In Listing 8, KEEP_CONNECTION is a constant that can be passed to the close() method. Itindicates that the underlying JDBC Connection object should not be closed.

The application must close the SQLJ connection context when it is done using it. Closing thecontext must be done with the KEEP_CONNECTION option set to false, as shown in Listing 9.

Listing 9. Scenario 4: Usage of KEEP_CONNECTIONpublic static final boolean KEEP_CONNECTION=false;myContext.close(KEEP_CONNECTION);

Failure to close the context with the KEEP_CONNECTION option will result in an exception inWebSphere Application Server as illustrated in Listing 10.




Page 9 of 17

Listing 10. Scenario 4: Exceptioncom.ibm.websphere.ce.cm.ObjectClosedException: DSRA9110E: Connection is closed.

Scenario 5: Caching a connection in an application

Listing 11 illustrates the scenario where a connection handle is cached and then reused acrosssuccessive servlet invocations. Each request to the servlet is serviced by a new separate threadand all these threads share a single connection handle.

Listing 11. Scenario 5: Caching a connection in an application/** * Servlet implementation class ServletTest */public class ServletTest extends HttpServlet {Connection conn=null;protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { try{ Context initialContext = new InitialContext(); DataSource ds1 =(DataSource)initialContext.lookup("java:comp/env/test"); if (conn==null){ conn = ds1.getConnection(); Statement stmt = conn.createStatement (); ResultSet rs = stmt.executeQuery ("select * from EMPLOYEE"); conn.close(); } else { Statement stmt = conn.createStatement (); ResultSet rs = stmt.executeQuery ("select * from EMPLOYEE"); conn.close (); } }catch(Exception e ) { // handle the exception e.printStackTrace(); } }}

Once the connection handle is closed, the next servlet request, which is a new thread, would try tocreate a statement on same closed handle and fail with ObjectClosedException, shown in Listing12.


Listing 12. Scenario 5: Exceptioncom.ibm.websphere.ce.cm.ObjectClosedException: DSRA9110E: Connection is closed.[2/14/12 11:55:07:768 IST] 0000001c SystemErr Rat com.ibm.ws.rsadapter.jdbc.WSJdbcWrapper.createClosedException(WSJdbcWrapper.java:109)[2/14/12 11:55:07:768 IST] 0000001c SystemErr Rat com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.activate(WSJdbcConnection.java:2812)[2/14/12 11:55:07:768 IST] 0000001c SystemErr Rat com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.createStatement(WSJdbcConnection.java:1605)[2/14/12 11:55:07:768 IST] 0000001c SystemErr Rat com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.createStatement(WSJdbcConnection.java:1585)



Page 10 of 17

Invoking the close() method on the connection handle frees up the connection to the free pool, andthe connection handle will still be available for reuse when getConnection() method is called on thedata source.

When the close method is not invoked on the connection handle, the connection is released to thefree pool at the end of the LTC and the connection handle is dissociated from the connection.

Scenario 6: Handling connection errorIn Listing 13, a connection handle is not closed by the application and is reused across successiveservlet invocations. In the event of a database hang or a network problem between WebSphereApplication Server and the database, the connection is marked as stale and the connection orconnection pool is purged, as per the configured purge policy.

Listing 13. Scenario 6: Handling connection Errorpublic class ServletTest extends HttpServlet { Connection conn=null; protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { try { Context initialContext = new InitialContext(); DataSource ds1 = (DataSource)initialContext.lookup("java:comp/env/test"); conn = ds1.getConnection(); Statement stmt = conn.createStatement (); //Database hang or network problem rs = stmt.executeQuery ("select * from EMPLOYEE"); rs.close(); stmt.close(); } catch (Exception e) { // handle exception e.printStackTrace(); } }}

Any subsequent request using the same connection handle will result in the exception illustrated inListing 14.


Listing 14. Scenario 6: Exceptioncom.ibm.websphere.ce.cm.ObjectClosedException: DSRA9110E: Connection is closed.

Scenario 7: Caching the ResultSet objects in an applicationIn Listing 15, the ResultSet object is cached and then reused across successive servletinvocations.

Listing 15. Scenario 7: Caching the ResultSet objects in an applicationpublic class ServletTest extends HttpServlet {



Page 11 of 17

ResultSet rs= null; Connection conn = null;

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { try{ Context initialContext = new InitialContext(); DataSource ds1 = (DataSource)initialContext.lookup("java:comp/env/test"); conn = ds1.getConnection(); if(rs==null){ Statement stmt = conn.createStatement(); rs = stmt.executeQuery("select * from EMPLOYEE"); } System.out.println(rs.next()); } catch (Exception e) { // handle exception e.printStackTrace(); } } }

When the LTC ends, the connection is returned back to the free pool, and child objects of theconnection including the ResultSet are closed. Therefore, any new request to access the cachedResultSet would encounter the exception shown in Listing 16.

Exception description (Listing 16): Attempted to perform an operation on a ResultSet object that isalready closed. Retrieve a new instance of the ResultSet object on which to perform the operation.

Listing 16. Scenario 7: Exception[3/14/12 17:14:26:667 IST] 00000023 SystemErr Rcom.ibm.websphere.ce.cm.ObjectClosedException: DSRA9110E: ResultSet is closed.[3/14/12 17:14:26:667 IST] 00000023 SystemErr R atcom.ibm.ws.rsadapter.jdbc.WSJdbcWrapper.createClosedException(WSJdbcWrapper.java:109)[3/14/12 17:14:26:667 IST] 00000023 SystemErr R atcom.ibm.ws.rsadapter.jdbc.WSJdbcResultSet.runtimeXIfNotClosed(WSJdbcResultSet.java:3359)[3/14/12 17:14:26:667 IST] 00000023 SystemErr R atcom.ibm.ws.rsadapter.jdbc.WSJdbcResultSet.next(WSJdbcResultSet.java:3130)[3/14/12 17:14:26:667 IST] 00000023 SystemErr R atServletTest.doGet(ServletTest.java:55)

Scenario 8: Application accessing a shareable cached connection acrosstransactions and methodsWhen an application accesses a shareable cached connection across transactions and methods, itfollows this pattern:

1. Get a connection2. Begin a global transaction3. Use the connection4. Commit a global transaction5. Use the connection again

Be aware that, Statements, PreparedStatements, and ResultSets are closed implicitly after atransaction ends, while the connection remains valid. Table 3 lists the valid and invalid sequence ofactions in this scenario.



Page 12 of 17

Table 3. Valid and invalid sequence of actionsValid Invalid (Exception will be thrown)

start transaction start transaction

get connection get connection

use connection use connection

Close connection

Commit transaction Commit transaction

pass connection to new method pass connection to new method

start new transaction start new transaction

use connection use connection

close connection close connection

commit transaction commit transaction

Related topicsHere are some of the custom properties and configurations in WebSphere Application Server thataffect multi-threaded access to a connection.

Re-using the connections across servletsDisableMultiThreadedServletConnectionMgmt is a custom property that is meant toallow connections to be reused across servlets. This property can be set as a web containercustom property (Figure 3). In the administrative console, navigate to Application servers> server_name > Web container > Custom properties. Create a property namedDisableMultiThreadedServletConnectionMgmt and set its value to true.

With this property enabled, if the connection handle is not closed and the servlet ends, the webcontainer, as part of postinvoke, parks the connection and does not close the connection handle.

Figure 3. Setting DisableMultiThreadedServletConnectionMgmt property

Non-transactional data sourcesa non-transactional data source specifies that the application server will not enlist the connectionsfrom this data source in global or local transactions. An application must explicitly callsetAutoCommit(false) on the connection if it wants to start a local transaction on the connection,and it must commit or rollback the transaction that they start.



Page 13 of 17

To enable a non-transactional data source, navigate form the administrative console to Datasources > datasource_name > WebSphere Application Server data source properties.

Select the Non-transactional data source checkbox (Figure 4).

Figure 4. Enabling non transactional data source

maxNumberOfMCsAllowableInThreadmaxNumberOfMCsAllowableInThread is a custom property that can be set on the connectionpool and helps in detecting higher than expected usage of number of managed connections on athread. Figure 5 shows the property set in the administrative console.

Figure 5. Setting maxNumberOfMCsAllowableInThread property

Sharing Local Transaction Containment (LTC)In WebSphere Application Server V7.0 and later, an LTC can be shareable; that is, a single LTCcan span multiple application components, including web application components and enterprisebeans that use container-managed transactions, so that these components can share connectionswithout using a global transaction.

This can be achieved by setting the Shareable attribute in the deployment descriptor of eachcomponent.



Page 14 of 17

When you set the Shareable attribute, the extended deployment descriptor XML file includes theline shown in Listing 17.

Listing 17. Setting Shareable attribute in extended deployment descriptor

<local-transaction boundary="BEAN_METHOD" resolver="CONTAINER_AT_BOUNDARY"unresolved-action="COMMIT" shareable="true"/>

Detecting MultiThreaded access to a connection

To determine the source of multi-threaded access in an application, you can enable theenableMultithreadedAccessDetection property on the data source. When this property hasa value set to true, the WebSphere Application Server relational resource adapter will log aDSRA8720W message if it detects multi-threaded access to JDBC objects. The exception alsoprovides Last Used ThreadId, Current ThreadId, and stack trace of the current thread.

To enable this property using the administrative console, navigate to Resources > JDBC > JDBCproviders > JDBC_provider > Data sources > data_source name > WebSphere ApplicationServer data source properties, and select the check box to enable this property (Figure 6).

Figure 6. selecting enableMultithreadedAccessDetection in administrativeconsole

Multi-thread use JCA programming model violation diagnostic alert

Multi-thread use of a connection raises an alert when an application component acquires aconnection handle using a connection factory, and then the component uses the handle ona different thread from which the handle was acquired. This can be enabled as part of thePerformance and Diagnostic Advisors from the administrative console, as depicted in Figure 7.



Page 15 of 17

Figure 7. Multi-threaded access – JCA programming model violationdiagnostic alert

Conclusion

This article provided information about the transition of connections between shared/unshared andfree pools and about the conditions that lead to such transitions. It also illustrated scenarios thatcould lead to multi-threaded access to a JCA connection, the various resulting exceptions, and themulti-threaded access detection capabilities in WebSphere Application Server.

Acknowledgements

The authors thank James M Stephens and Manu T George for their valuable suggestions andfeedback.



Page 16 of 17

Resources

• Default behavior of managed connections in WebSphere Application Server• WebSphere Application Server Information Center• Technote: SQLj Applications must close Connection Context after usage• Technote: Multiple thread access to a JDBC resource adapter object can cause an

IndexOutOfBoundsException exception• JDBC and SQLJ connection pooling support• Download WebSphere Application Server V8 trial• WebSphere Application Server product information• IBM developerWorks WebSphere

http://www.ibm.com/developerworks/websphere/library/techarticles/0506_johnsen/0506_johnsen.html

http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.home.doc_wasinfo_v8r0/welcome_ic_home.html

http://www-01.ibm.com/support/docview.wss?uid=swg21251464



http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.apdv.java.doc/src/tpc/imjcc_cjvjpool.html

http://www-01.ibm.com/software/webservers/appserv/was/

http://www-01.ibm.com/software/webservers/appserv/was/

http://www.ibm.com/developerworks/websphere/



Page 17 of 17

About the authors

Anoop Ramachandra

Anoop Ramachandra is a Senior Staff Software Engineer in IBM India SoftwareLabs. He has over eight years of experience on WebSphere Application Serverproduct as a Technical Lead, developer and Level 3 support engineer. His majorareas of expertise in WebSphere Application Server include System Management,Java EE Connector Architecture, Virtual Member Manager, Scheduler andAsynchronous beans. He is an IBM Certified System Administrator for WebSphereApplication Server.

Rispna Jain

Rispna Jain is a Technical Software Deployment Manager for WebSphere suiteof products in IBM Global Technology Services and works with clients in NorthAmerica. She has seven years of experience on WebSphere Application Serverproduct development at IBM Software Group in various roles such as development,L3 support and test. Rispna has also been a technical speaker for WebSphereApplication Server related topics at various WebSphere conferences. She is an IBMCertified SOA associate and holds a Master of Technology degree in ComputerScience.

© Copyright IBM Corporation 2012(www.ibm.com/legal/copytrade.shtml)Trademarks(www.ibm.com/developerworks/ibm/trademarks/)

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/developerworks/ibm/trademarks/

Documents

Application Server threaded access to a JCA connection in ...€¦ · Introduction. The IBM WebSphere Application Server connection pool helps to alleviate connection ... Understanding