db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: [VOTE] release
Date Wed, 21 Sep 2011 13:57:40 GMT
On 9/20/11 3:49 PM, Mike Matrigali wrote:
> Rick Hillegas wrote:
>> On 9/20/11 11:45 AM, Kathey Marsden wrote:
>>> On 9/20/2011 11:26 AM, Rick Hillegas wrote:
>>>> I have linked DERBY-5423 to DERBY-4437. This error can now appear 
>>>> as a result of the work done on DERBY-4437. It is possible that the 
>>>> error will go away if the default preallocation range for 
>>>> sequences/identities is boosted from 20 values to something bigger 
>>>> like 200. You might try re-running the test with this property 
>>>> setting:
>>>>    derby.language.sequence.preallocator=200
>>>> If that does fix the problem, then we may want to consider whether 
>>>> 20 is too low a default for this setting.
>>> Thank you Rick.  Once an appropriate default is determined, I think 
>>> it would be good to update the release note to include a specific 
>>> reference to this error and actions  to avoid it if it occurs on 
>>> upgrade. 
>> That sounds like a good idea.
>>> Sadly, I think it is something that users are not likely to hit 
>>> until they are in a heavily loaded production environment.  Is there 
>>> a way to acheive the prior behavior where there is not a risk of the 
>>> error occurring?
>> Here are some options:
>> 1) It's easy to achieve the prior behavior by backing out the fix for 
>> DERBY-4437. That would give up the concurrency boost provided by that 
>> work. I believe the user experience of the prior behavior is that 
>> access to the identity column goes down to single-threaded usage even 
>> at low contention levels. This could be done for 10.8.2.
>> 2) We could tackle the follow-on issue, DERBY-5295. That's a proposal 
>> to make Derby tune the preallocation cache size in a smarter way. 
>> That chunk of work is a mini-project and not a quick fix for 10.8.2.
>> Thanks,
>> -Rick
> Rick can you explain why we get the error rather than some sort of wait
> or retry.
The code is in SequenceUpdater.getCurrentValueAndAdvance(). We spin 
trying to get a new sequence number. If we spin longer than the lock 
timeout set by derby.locks.waitTimeout, then we raise this error.

Another workaround would be to set derby.locks.waitTimeout to a negative 
number so that there is no lock timeout.
> Can this error occur with the other things in the system that use 
> preallocated chunks, or is the specific to sequences.
> It seems like a bug to get an error in this case, and it even if we
> auto-tune better or set higher defaults it still seems like one could
> get an unexpected error.
We could spin forever. We could add another knob which controls the spin 
timeout. Other solutions?


View raw message