Re: [eclipselink-dev] Question about performanceissuewithSeqencingManage

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

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


> Andrei Ilitchev wrote:
> > ----- 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 have an estimate on when you will be working to commit it?
> > > 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).
> Thanks for the explanation. It clarifies my understanding.
>
> -Mitesh
> > 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
> >
> > _______________________________________________
> > 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