Re: WebSphere connection pool and deadlock - HELP!
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 PROTECTED] 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)
Re: WebSphere connection pool and deadlock - HELP!
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 PROTECTED] 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
WebSphere connection pool and deadlock - HELP!
We have a client who insists on using WebSphere 5.0. At first everything was fine, but all our database connections were created using JDBC connection logic. The client insists we use the JNDI naming context for finding and using the websphere connection pool and we began to encounter problems. The first problem was that sub-threads are not permitted under the servlet spec and so the behaviour if undefined. This shows up initially as the subthreads are not able to find the JNDI named context so nothing connects. My fix for this is to perform all actions in the current request response loop (no backgrounding). Now that I have everything connecting correctly I am creating a database deadlock constantly. Basically is seems that fetches are locking database rows, but the insert/updates are going to the database in a different connection and so are deadlocking on the same objects. No deadlock occurs until an INSERT is sent for an object related to a previous fetch. For example I can insert ActivityLogs all day since they have no relationships, but if I insert a new ContactLog for a Household .. dead. I have tried: - turning on concurrent request handling (thought it might change the fetch lock logic) - put in a custom SQLServerPlugin and overrode lockClause() to return an empty string. - did all editing in the session editing context - did initial fetches in the session EC, then all edits in a new EC - did initial fetches in the session EC, then all edits in a new EC with a new ObjectStoreCoordinator - reverting to straight JDBC, no pool works fine. I'm not sure where to go next. Other notes: - WebSphere 5.0.x deployed on SUSE - MS SQLServer 2000 - WebObjects 5.2.4 - Fastest way to reproduce is to submit a delta XML document via DirectAction POST. Thanks, David --- [EMAIL PROTECTED] (416) 513-9524 x263 Ticoon Technology Inc. 56 The Esplanade, Suite 404, Toronto, ON, M5E 1A7 ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
