Re: [eclipselink-dev] Question about performance issuewithSeqencingManag

["Andrei Ilitchev" <andrei.ilitchev@xxxxxxxxxx>]

----- Original Message ----- 
From: "Mitesh Meswani" <Mitesh.Meswani@xxxxxxx>
To: "Dev mailing list for Eclipse Persistence Services" 
<eclipselink-dev@xxxxxxxxxxx>
Sent: Friday, March 27, 2009 2:46 PM
Subject: Re: [eclipselink-dev] Question about performance 
issuewithSeqencingManager


> Hi Anderi,
>
> GlassFish always passes a nonJtaDataSource.  Are you suggesting that once 
> the bug is fixed EclipseLink would start using 
> Preallocation_Transaction_Accessor_State to allocate sequence numbers 
> under GlassFish?

Yes

> Do you think there is still a locking issue if a user ends up using 
> Preallocation_Transaction_NoAccessor_State? (Lets say a user running 
> outside GlassFish but using external transaction controller and not 
> providing nonJtaDaraSource)

There's a locking issue, but it's not much we can do about it.
In fact, introduction of sequencing connection pool (which uses 
Preallocation_Transaction_Accessor_State) was TopLink's answer for that.
The problem that in external transaction case the first thread to get to 
UPDATE SEQUENCE can deposit the new sequence values into preallocation 
bucket only after the external transaction has committed (it may be rolled 
back after the sequence values were obtained - in that case UPDATE SEQUENCE 
would be rolled back as part of the transaction and therefore the new 
sequence values should be discarded).

So in any case the second thread has to wait until the first thread 
transaction is completed.

The condition that sets keepLocked = true guarantees that transaction will 
be completed (and in case of success the new sequence values will be dropped 
into preallocation bucket) by the time the lock is released - so other 
threads waiting at the lock will immediately get access to new sequence 
values.

> Thanks,
> Mitesh
>
> Andrei Ilitchev wrote:
> > Mitesh,
> >
> > The best solution is to use sequencing connection pool - that's possible 
> > in case you use nonjtaDataSource (which used always to be the case with 
> > GlassFish?).
> > There's https://bugs.eclipse.org/bugs/show_bug.cgi?id=220402 describing 
> > the issue, the fix and the workaround.
> >
> > Thanks,
> >
> > Andrei
> > ----- Original Message ----- From: "Mitesh Meswani" 
> > <Mitesh.Meswani@xxxxxxx>
> > To: <eclipselink-dev@xxxxxxxxxxx>
> > Sent: Thursday, March 26, 2009 9:09 PM
> > Subject: [eclipselink-dev] Question about performance issue 
> > withSeqencingManager
> >
> >
> > > Hi,
> > >
> > > We seem to have a performance issue with Table Sequences while running 
> > > inside container ( => external transaction controller). If multiple 
> > > threads try to do getNextValue() on a table sequence and our 
> > > preallocation bucket is empty and external transaction controller is 
> > > used, all of them can reach the code at line 468 of 
> > > SequencingManager.Preallocation_Transaction_NoAccessor_State.getNextValue() 
> > > which calls sequence.getGeneratedVector(...) . This would result in all 
> > > of them issuing an update statement to the sequence table and being 
> > > blocked out by database till preceding threads' transaction commits. The 
> > > code of Preallocation_Transaction_NoAccessor_State.getNextValue() is 
> > > explicitly written to not obtain locks around 
> > > sequence.getGeneratedVector(...) if running with external transaction 
> > > controller. There is fair amount of comment written but some how I am 
> > > still not able to figure out why we are not obtaining locks for this 
> > > case. Can some one familiar with history of the code comment on this.
> > >
> > > Thanks,
> > > Mitesh
> > >
> > > _______________________________________________
> > > eclipselink-dev mailing list
> > > eclipselink-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
> >
> > _______________________________________________
> > eclipselink-dev mailing list
> > eclipselink-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev