db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: [VOTE] release
Date Tue, 20 Sep 2011 20:32:44 GMT
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?)

View raw message