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!
-Lars
|