db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Explaination to Derby-130 fix
Date Sat, 22 Jan 2005 16:34:46 GMT
Hash: SHA1

The bug for Derby-130 was that the method IDENTITY_VAL_LOCAL was not
being reset when a new connection was returned from a PooledConnection


Connection pooling is implemented in Derby by maintaining a
EmbedConnection object as the "physical" connection for the lifetime of
the PooledConnection object. The application receives through
PooledConnection.getConnection() a BrokeredConnection object (as the
logical connection) that wraps the EmbedConnection. The application can
never obtain a reference to the underlying EmbedConnection.
When the connection is re-used a new logical connection will be
comprised of a new BrokeredConnection object and the existing
EmbedConnection. The EmbedConnection remains valid until it has some
failure that closes it or the PooledConnection object is explicitly closed.

I saw this bug when I was cleaning up the internal handling of
IDENTITY_VAL_LOCAL to use long and Long and not long and BigDecimal. I
could see that the initial value of IDENTITY_VAL_LOCAL was meant to be
NULL but there was no mechanism to reset it. Thus it most likely would
break with pooling.

The fix (svn revision 126039) was simple, a specific reset mechanism
already existed to drop temporary tables which are private to a
connection. This method was dropAllDeclaredGlobalTempTables. I used the
same logic but renaming the methods to resetFromPool. I kept the
dropAllDeclaredGlobalTempTables method as-is but private in
GenericLanguageConnectionContext and added a new resetFromPool method
that reset the identity state and called the
dropAllDeclaredGlobalTempTables method.

There could be other state that needs to be added to this reset
mechanism. EmbedPooledConnection handles the resetting of all state that
can be done through standard JDBC method calls, such as isolation level.

Finally I added some tests in checkDataSource which run the same test
over a PooledConnection returned from EmbeddedConnectionPoolDataSource
and an XAConnection from EmbeddedXADataSource. This is because
XAConnection also implements PooledConnection.

Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


View raw message