db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xanana Gusmao <gmaneNov.20.geekrun...@spamgourmet.com>
Subject Re: Derby-638 not actually resolved ?
Date Wed, 13 Dec 2006 04:18:45 GMT
Bernt,

> 3) I would really hae liked to take peek at the connection pool your
>    are using to figure out what happens here. Where does this JdbcUtil
>    you are using coe from. Equinox?

Well I'm using Apache DBCP for the connection pool. However I don't get this
error when using the pool. I get this error when I'm directly creating the
connections via DriverManager.

Anyway the code snippet that I provided at the start of the thread wasn't the
actual code, line by line. In fact I have an additional closeStatement, as shown
below.

finally
{
    JdbcUtil.closeStatement( statementRowLock ); //2
    JdbcUtil.closeStatement( statementAddByOne ); //3
    JdbcUtil.closeConnection( conn ); //4
}

Query for "statementRowLock":
    select NUM from SEQUENCE where TYPE = ? FOR UPDATE

Query for "statementAddByOne":
    update SEQUENCE set NUM = ? where TYPE = ?

I learn new things everyday. And today, when I restored the closeStatements to
take place prior to the closeConnection (line marked 4);  I discovered that it
is the line marked 2 that's causing the SQLException. If I removed line 2, then
the code executes fine.

Note that JdbcUtil.closeStatement(..) looks like this.

    if (statement == null) return;    
    statement.close();

Basically after calling Statement.close();
inUnitOfWork_ was changed to true within
org.apache.derby.client.net.NetConnection.close().

And this leads to the SQLException. QED.


Mime
View raw message