Humm, It _should_ work like the following. The sequencer has a few reserved ids.
E.g. lastId = 312 reservedUntilId=349 while (lastId == reservedUntilId) goToDataBaseAndReserveTheNextBlock(); return ++lastId; And you are saying it goes to the database also if there is still a block of free reserved Ids left? Then this is a bug which should get addressed imo. We can easily create a unit test for it. LieGrue, strub --- On Wed, 1/26/11, Palmer Cox <[email protected]> wrote: > From: Palmer Cox <[email protected]> > Subject: Is there a desire to address OPENJPA-1376 (allocationSize incorrect > implementation)? > To: [email protected] > Date: Wednesday, January 26, 2011, 5:41 AM > The OPENJPA-1376 issue notes that the > allocationSize value on the > @SequenceGenerator annotation is not behaving as expected > (the issue > incorrectly states this behavior is set on the > @GeneratedValue annotation). > The behavior I'd expect is the same as described in the > issue - that the > allocationSize is used to control how often the sequence is > retrieved from > the database - ie, an allocationSize of 50 (the default, > according to > JSR-317) would mean that the next value of the sequence > would only be > retrieved every 50th call, and then other calls would just > increment the > previously retrieved sequence value by 1 and return. > Instead, the OpenJPA > implementation requests the next value of the sequence > every time a sequence > number is needed - this creates far more database calls > than would be > expected and may slow inserts down. JSR-317 could > certainly stand to be > more explicit in its definition of this attribute: "The > amount to increment > by when allocating sequence numbers from the > sequence." This definition > doesn't seem to to imply the "CACHE" value on the database > sequence object, > but rather the "INCREMENT BY" value. I don't see what > the point of > specifying the "INCREMENT BY" value would be if we continue > to go to the > database every time we need a sequence value. And > since the default value > is 50, I certainly don't see the value in specifying a > default increment of > more than 1 if we are going to go back to the database > every time we need a > value anyway. > > So, unless I'm missing something, this definitely seems > valid. Unless there > is something that I'm missing or some reason that this > behavior won't be > changed, I'm considering trying to come up with a patch to > address this > issue. However, I don't really have any interest in > coming up with a patch > and then finding out that there is some reason this code > can't or won't be > changed. > > -Palmer Cox >
