Palmer, I agree. Setting allocationSize > 1 should cache sequence values in jvm instead of just enabling sequence cache in database. That whould be a performance improvement when persisting entities and be consistent with table generator which features such caching.
If you want to create a patch, org.apache.openjpa.persistence.sequence.TestSequence might help. See also OPENJPA-466[1] for possible caveats. Good luck with the patch, that would be a valuable addition! Just don't assume it will take us 8h to complete as you estimated in JIRA :) Greetings, Milosz [1] https://issues.apache.org/jira/browse/OPENJPA-466 > 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 > > > > > >
