On 9/20/2011 12:20 PM, Rick Hillegas wrote:
at 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.
I was thinking more in terms of whether there is some safe value for a
user setting derby.language.sequence.preallocator, if an application
is not prepared for the new error, or some way for Derby to dynamically
slow things down to single threaded if there are more than 20
simultaneous inserts. (Is that the limitation is if the value is set to 20?)
