Re: [eclipselink-dev] Question about performance issue withSeqencingMana

[Mitesh Meswani <Mitesh.Meswani@xxxxxxx>]

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?

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)

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