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 such:
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
http://db.apache.org/derby/docs/10.8/ref/rrefproper46141.html
