What does J2CA0045E mean for WebSphere Application Server?
PMcAdams 120000FY75 Visits (9230)
I wanted to take some time to explain error "J2CA0045E: Connection not available while invoking method crea
When you configure a WebSphere Application Server managed datasource, you set two parameters that can directly affect this condition, the total number of connections you will allow the datasource to open (MAX connections), and in a case where all available connections are already active or in use, how long you will wait for one to complete and become available to service a new connection request (Connection Timeout).
In many cases, the default MAX connections value of 10 is simply too small to keep up with application demands, and the error can be eliminated by increasing the MAX connections allowed. Note that the WebSphere Application Server does not open database connections that your application does not request, so configuring a MAX value of 50 does not mean you are automatically going to generate 50 database connections, this is the number that you will allow to accumulate per your application. For example, if your application typically utilizes 20 database connections, then regardless of a MAX value of 25 or 250, you will still only average 20 open connections. However, you should also be aware of any maximum connection restrictions set at your database server. You never want your WebSphere Application Server to attempt to exceed the number of connections that your database server will allow.
If raising the MAX connection parameter on your failing datasource does not resolve this exception, or the MAX is already beyond what you consider a reasonable number, then chances are that your application is not properly utilizing the connection type specified. The WebSphere Application Server provides for two types of database connections, shared connections (default), and unshared. The basic difference between these types is that a shared connection, once obtained, will remain associated to the transaction that obtained it for the life of the transaction. This means that even if the application issues a close connection, the connection remains in the active connection pool, owned by the transaction, and will not be returned to the free pool for reuse until the transaction ends. This is for performance reasons, so that should that transaction require another connection, it does not have to go through the overhead of creating or obtaining a connection again.
With unshared connections, the database connection will be returned to the free pool, available for reuse, when the application makes the connection close request, regardless of the transaction state. If your local transactions are not making multiple connection request on the datasource, then there is no performance gain by using shared connections. In fact, the obverse could be the case. If your transactions are long running or suspending to do other work, you are needlessly holding on to database connections that could otherwise be returned to the free pool to be reused. So staying with the default connection type shared can adversely affect performance and be the cause of the Conn
This condition is quite easy to see in a WebSphere Application server diagnostic trace (*=i
There is an article written by one of our Staff Software Engineers in IBM WebSphere Application Server Connection Management that discusses the WebSphere Application Server connection behavior in some detail here: Defa
Switching connection types is quite easy thanks to a custom property introduced by development in APAR PK75717.
NOTE: If you do not see shared connections with handle counts = 0, then the application has not closed the connection(s) and switching to unshared connections will not resolve the problem. A handle count > 0 indicates that either the application is still using the connection or neglected to close it.