db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Katherine Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Derby Locks - best practices
Date Sat, 02 Jun 2012 00:45:59 GMT
On 6/1/2012 4:50 PM, Pavel Bortnovskiy wrote:
> Thank you, Dag.
> So, what may be my best strategy in the described situation? Let me recap a case like
> Say Derby is running in in-memory subprotocol. There are two tables and three threads.
Two threads perform inserts/deletes/updates and merges (implemented as update+insert) on each
corresponding table. And the third thread runs an SQL on those two tables. I forgot to mention
a few details:
> - the threads perform table updates in a batched way: Prepared statements are created
and then they are batched. At a certain the batches are executed
> - the SQL is very slow running - for argument sake, it may take 3-4 mins to run it -
much longer than a lock timeout.
> What would be the best way to assure proper functioning of the app and avoid timeouts?
> It has been suggested to repeat a transaction if a lock time out exception is caught,
but that would mean to execute the whole batch again...
You can set the timeout to be longer if that is acceptable to wait


View raw message