[castor-dev] CastorJDO, JBoss 3.0.4 connection not returned to pool AND castorbug 1162

[Thomas Klute]

Hi,

I just encountered two problems, one in jboss 3.0.4
source that is fixed in the current jboss-cvs version
but still occurs in the recent jboss 3.0.4 release.
The second problem was found in the current cvs version of
castor.
I thought it is useful to inform the castor users, who
pherhaps ran into the same problems:

I am using castor (current cvs version), jboss 3.0.4
and mysql using the jboss connection pool
(JBossManagedConnectionPool) and the jboss transactionmanager.

When accessing the database through an entity been and thus
opening a transaction managed by jboss I had the problem, that
the mysql connections were closed but not returned to the
connection-pool and jboss ran out of connections after a
short time ("No managed connections available"-Exception).
When explicitly calling db.close() before exiting the
session-bean-method all worked well, leaving out the db.close
caused the problem.
I traced the castor and jboss soure and found out, that
the BaseConnectionManager2-class in the jboss-source
has a bug:

public synchronized void registerConnection(Object handle)
{
handleCount++;
handles.add(handle);
}

public synchronized void unregisterConnection(Object handle)
{
handles.remove(handle);
handleCount--;
if (log.isTraceEnabled())
{
log.trace("unregisterConnection: " + handleCount);
} // end of if ()
}

public boolean isManagedConnectionFree()
{
return handleCount == 0;
}

I found out, that the connection was one time registered but
unregisterConnection was called two times when db.close wasn't
called before (don't ask why, but IMHO it should be no problem),
resulting in a -1 handlecount.
The connection is only returned to the pool, if
isManagedConnectionFree returns true.
I fixed that, by preventing the handle count to become negative:

...
handles.remove(handle);
if (handleCount>0)
handleCount--;
if (log.isTraceEnabled())
...

Current jboss-cvs-version checks if the handle-list is empty
in isManagedConnectionFree - so this problem won't occur in future
jboss-releases.

--------------------------------------------------------------
Second problem (castor-cvs-version):

Someone changed the file TransactionContextImpl.java in the cvs
(comment: Fixed Bug 1162: Castor should always set autoCommit to false)
by removing the "if ( ! _globalTx )" line (diff from 1.18 to 1.19 in cvs)

public Object getConnection( ...
...
conn = DatabaseRegistry.createConnection( engine );
if ( ! _globalTx ) //this line is removed in 1.19!!
conn.setAutoCommit( false );
...

This change causes an exception in my configuration:

Nested error: java.sql.SQLException: You cannot set autocommit during a managed transaction!
java.sql.SQLException: You cannot set autocommit during a managed transaction!
at org.jboss.resource.adapter.jdbc.local.LocalManagedConnection.setJdbcAutoCommit(LocalManagedConnection.java:447)
at org.jboss.resource.adapter.jdbc.local.LocalConnection.setAutoCommit(LocalConnection.java:426)
at org.exolab.castor.jdo.engine.TransactionContextImpl.getConnection(TransactionContextImpl.java:207)
at org.exolab.castor.persist.TransactionContext.query(TransactionContext.java:718)
at org.exolab.castor.jdo.engine.OQLQueryImpl.execute(OQLQueryImpl.java:521)

Is there something wrong with my configuration or do we have to reopen bug 1162?

Thanks and kind regards from dortmund,
Thomas

----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev