[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipselink-dev] Question about performance issue withSeqencingManager
|
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