Question

I am going through lock method of hibernate. I did not get what we are trying to achieve through this method.

 p1  = (Person)session. get(Person.class,1);// person name is scott here
// here peson name got update to henry by anothet thread
session. lock(person, LockMode.READ) line 3
// still name is henry too

I tried above code snippet but it did not read the person from database at line 3.
Documentation says that This may be used to perform a version check.

Not sure how does it check version and helps the developer in any scenario?

Similarly not sure what session.lock(person, LockMode.None) will achieve. Documentation says LockMode.NONE is used to to simply re-associate a transient instance with a session.

Not sure what does it mean by reassociating a transient instance with session. A brief scenario will be a great help?

Answer 1

The different lock-modes are meant for preventing the entity from being modified and read from multiple sources simultaneously, see the documentation entry about pessimistic locking for details. In my experience, these are rarely needed, as the database isolation level usually takes care of locking as needed:

It is not intended that users spend much time worrying about locking
strategies. It is usually enough to specify an isolation level for the
JDBC connections and then simply let the database do all the work.
However, advanced users may wish to obtain exclusive pessimistic locks
or re-obtain locks at the start of a new transaction.

As for the “reassociating a transient instance with the session” (I actually think they mean detached instance?), consider the following picture (Hibernate entity lifecycle):

This is the description from Hibernate community documentation:

Hibernate defines and supports the following object states:

• Transient – an object is transient if it has just been instantiated
  using the new operator, and it is not associated with a Hibernate
  Session. It has no persistent representation in the database and no
  identifier value has been assigned. Transient instances will be
  destroyed by the garbage collector if the application does not hold a
  reference anymore. Use the Hibernate Session to make an object
  persistent (and let Hibernate take care of the SQL statements that
  need to be executed for this transition).
• Persistent – a persistent
  instance has a representation in the database and an identifier value.
  It might just have been saved or loaded, however, it is by definition
  in the scope of a Session. Hibernate will detect any changes made to
  an object in persistent state and synchronize the state with the
  database when the unit of work completes. Developers do not execute
  manual UPDATE statements, or DELETE statements when an object should
  be made transient.
• Detached – a detached instance is an object that
  has been persistent, but its Session has been closed. The reference to
  the object is still valid, of course, and the detached instance might
  even be modified in this state. A detached instance can be reattached
  to a new Session at a later point in time, making it (and all the
  modifications) persistent again. This feature enables a programming
  model for long running units of work that require user think-time. We
  call them application transactions, i.e., a unit of work from the
  point of view of the user.