On 20.10.10 17:38, florin.herin...@sungard.com wrote:
Hi Kristian,
Changing of the global timeout is not an option, since I need to have most of the
statements behave normally (to wait as long as neccessary to succeed) and just a few
statements with a "fail fast" behavior.
I don't know if it is an option, but maybe it is possible to change the
lock timeout value (and possibly the deadlock timeout) if the query
timeout is smaller than the lock timeout value.
Is doing this acceptable in principle?
Does anyone know that piece of the code well enough to say if that's a
viable improvement?
Just a thought,
--
Kristian
The concrete problem: I have a kind of a timer that fires events at regular
intervals (5 sec) and I have to perform some actions. It might be possible
under certain circumstances that the performing of the actions take (much)
longer than the fixed rate of the timer, so that the next events are fired
before the long running one is finished. However, if the actions are involving
the same sets of rows, I want that the overlapping ones to fail fast and roll
back the transaction.
Now because Derby is waiting indefinitely, this scenario (events are comming
via jms messages) will lead to the consumming of all available database
connections, since for each jms message a new thread/transaction is created and
implicitely a new connection.
Regards,
Florin
-----Ursprüngliche Nachricht-----
Von: Kristian Waagan [mailto:kristian.waa...@oracle.com]
Gesendet: Mittwoch, 20. Oktober 2010 17:24
An: derby-user@db.apache.org
Betreff: Re: does Derby honor the statement.setQueryTimeout(int) ?
On 20.10.10 17:16, florin.herin...@sungard.com wrote:
Hi everybody,
I'm using Derby latest 10.6.2.1 and I'm having a problem with
statement.setQueryTimeout(int).
Namely I want to set a small value for the timeout (5 seconds) so that
the statement (an update statement) will fail (relatively) fast if
some other transaction is holding a write lock on the same row.
The problem is that setQueryTimeout seems to be ignored, and the
update is waiting until the global timeout - 60+ seconds.
Is that a known problem with Derby ? Or am I doing something wrong ?
Hi Florian,
I'm not sure, but if Derby is waiting for a lock, it may not honor the query
timeout.
If the statement is doing "normal processing", the query timeout should take
effect. If your application code is set up correctly for retrying, is it an option to
lower the lock timeout as well?
Regards,
--
Kristian
Best Regards,
Florin Herinean
