Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Question about performance issuewithSeqencingManager


----- 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




Back to the top