users@glassfish.java.net

Re: READ_UNCOMMITTED with GlassFish+TopLink - Problem

From: <glassfish_at_javadesktop.org>
Date: Fri, 02 Nov 2007 13:01:37 PST

Marina

We did some rethinking about our problem with READ UNCOMMITTED. READ UNCOMMITTED is actually for the case where in the situation of a concurrent transaction, an uncommitted data made by transaction #1 can be read by transaction #2. Thus the 'dirty read' problem. We are NOT dealing with this, the issue we're facing it WITHIN one transaction.

Basically, we need to get the KEY from the first insert for the second insert within one transaction. We know of the hack we need to do in TopLink to get the KEY from the first insertion. There is a second part to the problem. With Toplink we have to call flush() after calling persist() for Location. Hibernate somehow does not require this – I think this is not in the spec.

Anyway for the benefit of other GlassFish-TopLink users, when u call entityManager.flush() within a transaction it is not actually stored in db (but now available as transient data within the transaction context for others to see it), which is expected. In other words, we could rollback if an exception occurs. Hibernate and Toplink handle things differently, which affect our persistence coding. Who knows, maybe Hibernate internally calls flush() and TopLink do not.

In the case of a relationship 'link' between Location and Landmark, it works (Tim tested it briefly) because the definition of relationship tells toplink there is dependency and I'm suspecting internally it flushes Location before storing Landmark. However, we want to avoid “linking” the tables as we want to the “lazy” performance.

I do read that flush() may have performance issue (need to confirm it), we need to use it sparingly where needed like in the case of Landmark where we are storing to multiple tables and there's foreign key dependency. We'll know about performance when we do load test on it once we fully migrated to GF.

So we are flush()-ing selectively is the solution for now.

PS: I think CMT/XA is a bug. You probably have our test package by now. The work around to use BMT/XA is too painful.

Regards,
Kevin + Tim + Patrick
[Message sent by forum member 'moblast' (moblast)]

http://forums.java.net/jive/thread.jspa?messageID=243587