[hibernate-dev] JPA2 locking

[Steve Ebersole]

Hey Thamayanthi, 

It really depends what interests you.  If you don't know the code base
very well, that would be a good place to start.  Also don't discount
helping out on IRC or forums or documentation etc.  Those are great ways
to help improve hibernate.

In terms of developing code, the best bet is to find some JIRA issues
that meet you level of experience with Hibernate source code and fix
those bugs.  We can help identify potential JIRA issues, but like I said
it really is best if we understand your areas of interest or if you find
them based on those interests.

On Thu, 2009-10-22 at 06:57 -0300, Thamayanthi Guhan wrote:
> Hello Everyone,
> 
> I would like to contribute in  hibernate developement. Can any one provide
> guidance to start?
> 
> Thanks
> Thamayanthi
> 
> On Tue, Oct 20, 2009 at 10:45 AM, Scott Marlow <smarlow at redhat.com> wrote:
> 
> > On 10/16/2009 03:40 PM, Emmanuel Bernard wrote:
> > > When I discussed that with Gavin, I believe this idea is that you can
> > > implement the optimistic locking in the following way:
> > >  - when locking an object read the version number (or if already
> > > loaded keep this one - not sure about that detail)
> > >  - when flushing or right before commit, read the version number again
> > > from the database and compare.
> > > If they are different => exception
> > >
> > > A provider may but is not forced to acquire the lock
> > >
> > > Note that today we implement Optimistic in a pessimistic way (ie que
> > > acquire the DB lock right away).
> > >
> > > So there are three levels really
> > > no lock => we check versions upon UPDATE operations
> > > optimistic => we check versions on reads as well and verify consistency
> > > pessimistic => we lock at the DB level.
> >
> > Currently, the Hibernate EM depends on Hibernate core for locking (as it
> > should).  I have a few questions about how achieve the above locking
> > with Hibernate core and about what changes are needed.
> >
> > The JPA 2 locking operations that we need support for are:
> >
> > OPTIMISTIC (equal to READ) - should read the version initially and
> > confirm that it hasn't changed at transaction commit time.  We should
> > throw OptimisticLockException if the version has changed.  I think that
> > we need a new LockMode for this (similar to LockMode.READ).  For
> > extended persistence context (meaning that the duration is beyond the
> > end of transaction), I think that we use the entity value from the
> > extended persistence context as is but should still confirm that it
> > hasn't changed at commit time (optimistically assume that it hasn't
> > changed initially).
> >
> > OPTIMISTIC_FORCE_INCREMENT (equal to WRITE) - should read the version
> > initially.  At transaction commit time, confirm that the version hasn't
> > changed as we increment it via update.  We should throw
> > OptimisticLockException if the version has changed.  I think that we
> > need a new LockMode for this (similar to LockMode.READ and
> > LockMode.FORCE).  Same rules as above for extended persistence context.
> >
> > PESSIMISTIC_WRITE - Should obtain a database write lock on the entity.
> > Hibernate LockMode.Upgrade could be used for this on dialects that
> > support it.  For dialects that don't support LockMode.Upgrade, a
> > PessimisticLockException should be thrown.
> >
> > PESSIMISTIC_READ - Should obtain a shared database read lock on the
> > entity (for the duration of the database transaction).  How should we
> > support this?  The JPA 2 specification allows the PESSIMISTIC_WRITE
> > behavior to be used.
> >
> > PESSIMISTIC_FORCE_INCREMENT - Same as PESSIMISTIC_READ but with an
> > increment version at transaction commit time (even if entity isn't
> > updated).  I think that we need a new LockMode for this.  We need a way
> > to throw an exception if not supported.
> >
> > For pessimistic locks, only lock element collections and relationships
> > owned by the entity, if property javax.persistence.lock.scope is set to
> > "PessimisticLockScope.EXTENDED".
> >
> > Assuming we do the above, we need to release note that READ/WRITE locks
> > are obtained in optimistic manner which is a change from our JPA 1 support.
> >
> > Comments?
> >
> > Any volunteers willing to help with JPA 2 implementation (coding,
> > testing, moral support) are welcome to join in.:-)
> >
> > Scott
> >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
-- 
Steve Ebersole <steve at hibernate.org>
Hibernate.org