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 Tue, 20 Sep 2011 19:20:00 GMT
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.


View raw message