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.
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.
