Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4E78DF67.2020608@sbcglobal.net>
Date: Tue, 20 Sep 2011 11:45:59 -0700
From: Kathey Marsden <kmarsdenderby@sbcglobal.net>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
 rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: [VOTE] 10.8.2.1 release
References: 
 <CADjEm_UUrLtusqAou2eUKpuF1tEeddV7Fg8jzkVLaGrmP9Twjw@mail.gmail.com>
	<x61uvjsewb.fsf@oracle.com>	<x6wrdbqzx1.fsf@oracle.com>
	<32462975.post@talk.nabble.com>
	<CADjEm_Ubun90+tyx3b=M1Bd1T5t8hJuC++LN8kyOQOsgQGg=mw@mail.gmail.com>
	<CAFy7pk-yZHmedCKz88FuNeT-p+4mAHFZhBAxGMSy4j89bSAB6g@mail.gmail.com>
	<CAAkOS7ijzH6YC0yQyo9GU-EZUpCgbMXECoe9wOiQSjf2ACTkmQ@mail.gmail.com>
	<CADjEm_Uu5pq_24XeJrO3d_KyzP=6OWQ5RQfH3UgZVDKZq59PXw@mail.gmail.com>
	<4E78CB3F.7040109@sbcglobal.net>
 <CADjEm_UwU-DMN9imsWXvhntbk0yDsyX+O2sgPK9cQGU1pTuoiQ@mail.gmail.com>
 <4E78DAEB.6090504@oracle.com>
In-Reply-To: <4E78DAEB.6090504@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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