Re: Object Locking and Application Server (container-managed) environment

[Craig L Russell]

Hi Kevin,




Craig

On Sep 26, 2007, at 6:00 AM, Kevin Sutter wrote:

The transaction model for Kodo is based on the pretty well documented JDO specification which includes both optimistic and datastore transaction semantics. To this model were added the explicit locking APIs which complicate things just a bit. But reading the JDO spec might be a good start to understand how Kodo worked and therefore how OpenJPA's underpinnings work. Ducking now in case there have been massive changes to OpenJPA to remove these architecture features...

Discovered a useful openjpa property...

On 9/25/07, Kevin Sutter <[EMAIL PROTECTED]> wrote:

Hi,

they relate to running OpenJPA within an application server

these properties and/or API's are assuming an application-managed



OpenJPA supposed to honor the "none" ReadLockLevel request?


optimistic and non-optimistic (pessimistic) transactions.  Not lock
managers, but transactions.  The OpenJPA manual indicates that it can

the use of optimistic vs pessimistic transactions.  It looks like the

I'm trying to figure out the ins and outs of Section 3 Object Locking as (container-managed) environment such as WebSphere. It seems that several of environment outside of a container. Either that, or there are implied behaviors of the container environment that WebSphere is not providing. For example, the ReadLockLevel property allows for none, read, or write values. What does it mean for "none" in an application server environment? If the Container has already initiated a global (JTA) transaction, when OpenJPA requests a Connection (via the <jta-data-source> element), this Connection is automatically enlisted in the Transaction. Thus, when the "Select..." statement is issued, we will get a Read Lock on the row with the default isolation level setting (supposed to be Read Committed). So, how is Several places in this section of the document, there are references to support optimistic transactions by not issuing the database transaction until flush or commit time. But, I don't see how we are can configure for EntityTransaction interface is optimistic by default. But, is there anyway to control the optimisticity (new word) of a global transaction? The answer to these questions actually help with the first example outlined above.

to indicate whether to use optimistic or non-optimistic transaction
semantics.  So, it's not just an implicit operation.  But, I guess my
question still exists on how this applies to container managed JTA

experts in this area, I'd appreciate some insights.  :-)  Thanks!

Okay. It was pointed out to me that the openjpa.Optimistic property exists transactions. I will continue to investigate, but if there are any existing Many other similar questions are in my mind, but let's start with these

since I think these will give a basis for the rest of the discussion.

Thanks,
Kevin

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature