Lists

Terms and Conditions
Lists hosted on this site
Email the Postmaster
Tips for posting to public mailing lists

Re: WebSphere connection pool and deadlock - HELP!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WebSphere connection pool and deadlock - HELP!

Subject: Re: WebSphere connection pool and deadlock - HELP!
From: David Aspinall <email@hidden>
Date: Mon, 8 May 2006 16:18:37 -0400

I am wondering now if the problem could be the way the applications are packaged as an EAR file. We are currently deploying as 5 different applications within websphere, using one EAR file to deploy all. My new understanding suggests that websphere allocates only one child JVM for the ear file. (as opposed to deploying them as 5 separate EAR or WAR files, where I would get 5 separate JVM's)

Could this be the problem?  Does anyone have any experience with this?

David

On 4-May-06, at 1:25 PM, Michael Parlee wrote:

Well you've got me. I didn't realize that the PoolingJDBCAdapter uses its own connection pool. I guess I might look at that source code and try to modify it do a JNDI lookup for a connection pool on the app server. Other than that I don't know what to suggest, I can't find anything on the web about WO and J2EE connection pools.

The fact that your object store coordinators are deadlocking makes me wonder if in using a new object store coordinator for each EC you are having issues with related objects being spread across multiple object stores.
Sorry, I wish I could be more help.
Mike
On Wednesday, May 03, 2006, at 08:45AM, David Aspinall <email@hidden> wrote:
Thanks Michael,
I am not using the PoolingJDBCAdaptor.  The connection is configured
in WebSphere and obtained using JNDI.  My raw query tool uses the
following to find the connection
try
{
	String contextName = "java:comp/env/jdbc/DefaultDataSource";
	InitialContext ctx = new InitialContext();
	datasource = (DataSource)ctx.lookup( contextName );
	connection = datasource.getConnection();
}
catch (NamingException e)
{
	Log.Debug( this.getClass().getName() + ".findJNDIDatasource
( InitialContext ): Could not find JNDI/JDBC Context for name '" +
contextName + "'");
	throw e;
}
The problem is not with the raw query tool (in fact the problem takes
place without even having used the query tool), the problem is with
the regular EOF access.  When I give each new EOEdtingContext it's
own ObjectStoreCoordinator, then I get a full stack, and a new
connection for each stack.  EOF seems to find the connections without
any problem, but it is locking objects in one stack (connection) that
I am trying to save in a different stack.  I just cannot see why.
The problem also occurs when I use the session default EC for
everything, so there should only be one stack...
When I kill the connection using EnterpriseManager for SQLServer I
get the following backtrace
[5/3/06 12:49:38:160 BST] 291adf4c SystemErr R [Imports]: DEBUG: com.webobjects.jdbcadaptor.JDBCAdaptorException: DSRA9110E: Connection is closed. at com.webobjects.jdbcadaptor.JDBCContext.rollbackTransaction (JDBCContext.java:453) at com.webobjects.eoaccess.EODatabaseContext.rollbackChanges (EODatabaseContext.java:6607) at com.webobjects.eoaccess.EODatabaseContext.commitChanges (EODatabaseContext.java:6483) at com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditin gCo ntext(EOObjectStoreCoordinator.java:425) at com.webobjects.eocontrol.EOEditingContext.saveChanges (EOEditingContext.java:3187) at ticoon.edit.ValidatingEOCollectionEditor.saveChanges (ValidatingEOCollectionEditor.java:222) ....

[5/3/06 12:49:38:953 BST] 291adf4c WSRdbManagedC W DSRA0180W: Exception detected during ManagedConnection.destroy(). The exception is: com.ibm.ws.exception.WsException: DSRA0080E: An exception was received by the Data Store Adapter. See original exception message: [IBM][SQLServer JDBC Driver]No more data available to read.. with SQL State : 08006 SQL Code : 0 at com.ibm.websphere.jdbc.base.BaseExceptions.createException() at com.ibm.websphere.jdbc.base.BaseExceptions.getException() at com.ibm.websphere.jdbc.base.BaseExceptions.getException() at com.ibm.websphere.jdbc.sqlserver.tds.TDSExecuteRequest.submitRequest( ) at com.ibm.websphere.jdbc.sqlserver.SQLServerImplConnection.rollbackTran sac tion() at com.ibm.websphere.jdbc.base.BaseConnection.rollback() at com.ibm.websphere.jdbcx.base.BasePooledConnection.rollback() at com.ibm.websphere.jdbcx.base.BaseConnectionWrapper.rollback() at com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanupTransactio ns( WSRdbManagedConnectionImpl.java:2626) at com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.destroy (WSRdbManagedConnectionImpl.java:2068) at com.ibm.ejs.j2c.MCWrapper.destroy(MCWrapper.java:1380) at com.ibm.ejs.j2c.poolmanager.FreePool.cleanupAndDestroyMCWrapper (FreePool.java:506) at com.ibm.ejs.j2c.poolmanager.FreePool.returnToFreePool (FreePool.java:318) at com.ibm.ejs.j2c.poolmanager.PoolManager.release (PoolManager.java:1309) at com.ibm.ejs.j2c.MCWrapper.releaseToPoolManager (MCWrapper.java:1766) at com.ibm.ejs.j2c.LocalTransactionWrapper.afterCompletionCode (LocalTransactionWrapper.java:1092) at com.ibm.ejs.j2c.LocalTransactionWrapper.afterCompletion (LocalTransactionWrapper.java:1026) at com.ibm.ws.LocalTransaction.LocalTranCoordImpl.informSynchronizations (LocalTranCoordImpl.java:1309) at com.ibm.ws.LocalTransaction.LocalTranCoordImpl.cleanup (LocalTranCoordImpl.java:1038) at com.ibm.ws.webcontainer.webapp.WebAppTransactionCollaborator.postInvo ke( WebAppTransactionCollaborator.java:249) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch (WebAppRequestDispatcher.java:852) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward (WebAppRequestDispatcher.java:203) at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward (WebAppInvoker.java:125) at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook (WebAppInvoker.java:300) at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvoc ati on(CachedInvocation.java:71) at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI (ServletRequestProcessor.java:246) at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service (OSEListener.java:334) at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest (HttpConnection.java:56) at com.ibm.ws.http.HttpConnection.readAndHandleRequest (HttpConnection.java:652) at com.ibm.ws.http.HttpConnection.run(HttpConnection.java: 448) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:936)
But this is just a reaction to the connection being closed on the
server.
Any ideas?
David
On 3-May-06, at 9:16 AM, Michael Parlee wrote:
Hi David,
You didn't explain how you accessed the connection pool from WO.
Are you using Lenny Marks' PoolingJDBCAdapter?  If not here is the
link to that code on WOCode:
http://wocode.com/cgi-bin/WebObjects/WOCode.woa/2/wa/ShareCodeItem?
itemId=330
Sorry I can't be of more help, I've never tried this before.
I have written J2EE apps that directly obtain a JDBC connection
from a pool and I can tell you there is nothing special about the
JDBC connection.  The problem for WebObjects is that the connection
is returned to the pool between transactions whereas the WO wants
to hang on to one connection for the life of the EO stack.  I
suspect even with Lenny's pooling adapter this could cause problems
that must be worked around.
Good luck,
Mike


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden



Prev by Date:
Re: Too Many Sessions Are Being Generated

Next by Date:
Re: Too Many Sessions Are Being Generated

Previous by thread:
WebSphere connection pool and deadlock - HELP!

Next by thread:
Re: WebSphere connection pool and deadlock - HELP!

Index(es):

Date
Thread