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: Fri, 12 May 2006 14:11:48 -0400

Ok, that doesn't seem to be the issue. I have been searching the web (again) and I have identified 2 possible problem areas.

One: seems there may be a problem with WebSphere connection pools prematurely closing when the connection/statement/resultset are all in different declared scopes. Seems odd to me but there were several reports where the problem (like mine) went away when the connection/ statement/resultset were all declared locally, used and released within the same scope. Unfortunately I do not see a way to make WebObjects act this way :<

Two: seems there may be a problem with WebSphere connection pools where the user (WebObjects) tries to set the autocommit flag (either true or false). Since I know WO does set the connection to autocommit false, I am again stuck.

Does this sound familiar to anyone?  Suggestions ... please.

David


On 12-May-06, at 1:48 PM, David Aspinall wrote:

Ok, that doesn't seem to be the issue. I have been searching the web (again) and I have identified 2 possible problem areas.

One: seems there may be a problem with WebSphere connection pools prematurely closing when the connection/statement/resultset are all in different declared scopes. Seems odd to me but there were several reports where the problem (like mine) went away when the connection/statement/resultset were all declared locally, used and released within the same scope. Unfortunately I do not see a way to make WebObjects act this way :<

Two: seems there may be a problem with WebSphere connection pools where the user (WebObjects) tries to set the autocommit flag (either true or false). Since I know WO does set the connection to autocommit false, I am again stuck.
Does this sound familiar to anyone?  Suggestions ... please.
David
On 8-May-06, at 4:18 PM, David Aspinall wrote:
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.saveChangesInEdit ingCo 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.submitReques t() at com.ibm.websphere.jdbc.sqlserver.SQLServerImplConnection.rollbackTr ansac 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.cleanupTransact ions( 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.informSynchronizatio ns (LocalTranCoordImpl.java:1309) at com.ibm.ws.LocalTransaction.LocalTranCoordImpl.cleanup (LocalTranCoordImpl.java:1038) at com.ibm.ws.webcontainer.webapp.WebAppTransactionCollaborator.postIn voke( 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.handleInv ocati 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



References:  
  >Re: WebSphere connection pool and deadlock - HELP! (From: David Aspinall <email@hidden>)




Prev by Date:
Re: seamleass integration with other application

Next by Date:
Help on big relationship

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

Next by thread:
Re: Bug in WOContext.directActionURLForActionNamed() when using	query dictionary

Index(es):

Date
Thread