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?
Thanks,
-Rick
