openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: Object Locking and Application Server (container-managed) environment
Date Wed, 26 Sep 2007 19:56:38 GMT
Thanks, Craig and Patrick, for the background.  That information helps with
understanding some of the loopholes.  At a minimum, it looks like our
documentation might need a little bit of work in this area.  Hopefully with
this string of notes, I can make some sense out of it and update the docs
appropriately.

It seems that we have a few semantics that need clarifying:

o  optimistic vs non-optimistic transactions
o  and, how these relate or do not relate to datasource transactions
o  and, now these interact or do not interact with JTA vs EntityTransaction
transactions

This seems separate from (but still related to) the lock manager story:

o  optimistic (version) lock manager - default
o  pessimistic lock manager
o  none lock manager

Now, on to some of Patrick's comments...

On 9/26/07, Patrick Linskey <plinskey@gmail.com> wrote:
>
>
> So, naming around locking is not ideal in OpenJPA. First, it's
> important to note that optimistic locking happens whenever there is a
> versioning strategy configured for a class, regardless of pessimistic
> locking. So, optimistic locking is implemented completely separately
> from pessimistic locking.


This paragraph confuses me.  How does optimistic locking happen regardless
of pessimistic locking?  I don't get what this is stating.  Are you saying
that even if the pessimistic lock manager is configured, then you will still
get optimistic locking if there's a configured version strategy configured?
Since the version strategy is default, then how do we ever get pessimistic
locking?  Or, are we referring to the pessimistic locking configuration
properties and API's?

The LockManager is there for pessimistic locking. So, the different
> calls (and the Read and Write LockLevels) control what level of
> locking the LockManager should attempt to obtain. As you allude to,
> and as is always the case with locking, if you request a lower lock
> level than the connection is providing, OpenJPA won't step the lock
> level down, so if you ask for a ReadLockLevel of none and are using
> read-committed, then you'll really be getting read-committed locking
> on reads.


Good.  This makes sense and is a nugget for the documentation updates.

Thanks for the discussion,
Kevin

-Patrick
>
> On 9/26/07, Craig L Russell <Craig.Russell@sun.com> wrote:
> > Hi Kevin,
> >
> > 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...
> >
> > Craig
> >
> > On Sep 26, 2007, at 6:00 AM, Kevin Sutter wrote:
> >
> > > Discovered a useful openjpa property...
> > >
> > > On 9/25/07, Kevin Sutter <kwsutter@gmail.com> wrote:
> > >>
> > >> Hi,
> > >> I'm trying to figure out the ins and outs of Section 3 Object
> > >> Locking as
> > >> they relate to running OpenJPA within an application server
> > >> (container-managed) environment such as WebSphere.  It seems that
> > >> several of
> > >> these properties and/or API's are assuming an application-managed
> > >> 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
> > >> OpenJPA supposed to honor the "none" ReadLockLevel request?
> > >>
> > >> Several places in this section of the document, there are
> > >> references to
> > >> optimistic and non-optimistic (pessimistic) transactions.  Not lock
> > >> managers, but transactions.  The OpenJPA manual indicates that it can
> > >> 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
> > >> the use of optimistic vs pessimistic transactions.  It looks like the
> > >> 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.
> > >
> > >
> > > Okay.  It was pointed out to me that the openjpa.Optimistic
> > > property exists
> > > 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
> > > transactions.  I will continue to investigate, but if there are any
> > > existing
> > > experts in this area, I'd appreciate some insights.  :-)  Thanks!
> > >
> > > 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:Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
> >
> >
>
>
> --
> Patrick Linskey
> 202 669 5907
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message