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