You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Fl...@sungard.com on 2010/10/20 17:16:49 UTC
does Derby honor the statement.setQueryTimeout(int) ?
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 ?
Best Regards,
Florin Herinean
Re: AW: does Derby honor the statement.setQueryTimeout(int) ?
Posted by Lily Wei <li...@yahoo.com>.
Hi Florin:
So glad to hear derby user is using 10.6.2.1. I suspect there might be
something more complicated than Statement.QueryTimeout was not working. Is it
possible for you to reproduce a smaller test case to allow people to further
investigate the case?
Like Kristian pointed out, Statement.QueryTimeout should take effect. I
attach a repro that is using Statement.QueryTimeout. I tested against 10.6.2.1
release and it is working for me.
Best Regards,
Lily
________________________________
From: "Florin.Herinean@sungard.com" <Fl...@sungard.com>
To: derby-user@db.apache.org
Sent: Wed, October 20, 2010 8:38:11 AM
Subject: AW: does Derby honor the statement.setQueryTimeout(int) ?
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.
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.waagan@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.Herinean@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
>
AW: AW: does Derby honor the statement.setQueryTimeout(int) ?
Posted by Fl...@sungard.com.
Hi Knut, Lily,
I have created ticket https://issues.apache.org/jira/browse/DERBY-4863 and attached a sample program to reproduce it.
Since in the meantime I was able to circumvent the concrete problem by adding a dedicated locking mechanism in *our* code, the priority for the ticket is "none" from my point of view. However, since the problem exists I've created the ticket as you suggested and also attached code to reproduce.
Best Regards,
Florin
-----Ursprüngliche Nachricht-----
Von: Knut Anders Hatlen [mailto:knut.hatlen@oracle.com]
Gesendet: Mittwoch, 20. Oktober 2010 20:04
An: derby-user@db.apache.org
Betreff: Re: AW: does Derby honor the statement.setQueryTimeout(int) ?
Kristian Waagan <kr...@oracle.com> writes:
> On 20.10.10 17:38, Florin.Herinean@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?
Hi Kristian,
I think this is possible. The lock manager could retrieve information about the query timeout from the statement context, and then if necessary use that to shorten the lock timeout. It sounds like a bug that we don't already do that.
Florin, please file a bug report in JIRA so that we can keep track of this problem.
Thanks,
--
Knut Anders
Re: AW: does Derby honor the statement.setQueryTimeout(int) ?
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Kristian Waagan <kr...@oracle.com> writes:
> On 20.10.10 17:38, Florin.Herinean@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?
Hi Kristian,
I think this is possible. The lock manager could retrieve information
about the query timeout from the statement context, and then if
necessary use that to shorten the lock timeout. It sounds like a bug
that we don't already do that.
Florin, please file a bug report in JIRA so that we can keep track of
this problem.
Thanks,
--
Knut Anders
Re: AW: does Derby honor the statement.setQueryTimeout(int) ?
Posted by Kristian Waagan <kr...@oracle.com>.
On 20.10.10 17:38, Florin.Herinean@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.waagan@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.Herinean@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
>>
>
>
AW: does Derby honor the statement.setQueryTimeout(int) ?
Posted by Fl...@sungard.com.
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.
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.waagan@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.Herinean@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
>
Re: does Derby honor the statement.setQueryTimeout(int) ?
Posted by Kristian Waagan <kr...@oracle.com>.
On 20.10.10 17:16, Florin.Herinean@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
>