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
