db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Clausen ...@statsbiblioteket.dk>
Subject Re: Locks not released on error
Date Fri, 23 Sep 2005 08:09:28 GMT
On fre, 2005-09-23 at 09:43, Øystein Grøvlen wrote:
> >>>>> "LC" == Lars Clausen <lc@statsbiblioteket.dk> writes:
>     LC> Hi!
>     LC> We're using Derby version 10.1 (Bundle-Version: 10.1.1000000.208786)
>     LC> embeddedly in our system.  Even though I've put extensive rollback and
>     LC> statement closing handling in the code, we still occasionally see cases
>     LC> where a table gets permanently locked after an error during update
>     LC> (detail below).  Is there something other than closing open statements
>     LC> and rolling back existing savepoints that could be required for
>     LC> releasing locks?  Am I doing the closing/rolling back wrongly?  Any
>     LC> other ideas on how to cure this would be welcome.
> Lars,
> Note that rolling back to savepoints does not roll back the entire
> transaction.  This means that locks set by the transaction are not
> released.  In order to release locks you need to do call
> Connection.rollback() (without any parameters).

I see.  Sun's javadoc is not entirely clear on that, but I now found it
deep in the Derby docs.  So essentially, I should avoid using explicit
savepoints without a very good reason, but just do Connection.rollback
in the finally block (since it would normally come after the
Connection.commit call, it shouldn't matter when things go well, unless
there's a performance hit on trying a rollback right after a commit?)

Thanks for the help!


View raw message