On fre, 2005-09-23 at 09:43, Øystein Grøvlen wrote: > >>>>> "LC" == Lars Clausen <[EMAIL PROTECTED]> 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
