Hi there!

As a newcomer in Hibernate, i try to understand the technique supported by Hibernate, but have some general questions where i find no answers..

If i do some update on several objects in a session, the changes take just affect to the local objects until the session is committed, right?

Now what happens, if we have two applications on two JVMs using hibernate, executing such a query on the same object?
Does Hibernate can prevent the database from having Persistence-Error?
Which is a correct strategy for the right "HighLevelLocking"?

Sample:
APP A, Machine A
- Start Session
- Load User-Object (ID=3)
- Increment SomeCounter via Method
- Commit Session

APP B, Machine B
- Start Session
- Load User-Object (ID=3)
- Increment SomeCounter via Method
- Commit Session

How does the Object-Locking is being propagated to the Database-Layer
or in case of a needed "Object-Takeover-Process" for Object Ownership,
how do we correctly lock this takeover to exclude concurrent takeover?

Thank You for any explanation or any hints on other info-sources

Either use explicit locking (LockMode) or optimistic locking (version, timestamp)

Thanks, that seems to be the way...
I was searching in the reference for the keyword "lock" and found many inputs for my general questions. Mainly this topic is discussed on the chapter @10.4 (Page79)

The declaration of a class supports the following configuration @5.3.1
optimistic-lock="none|version|dirty|all"
Some text on the page tells:
"We very strongly recommend that you use version/timestamp columns for optimistic locking with Hibernate."
Does it meand the following exact Configuration to be recommended:
optimistic-lock="version"

Another @9.4.3 is written:
"The lock() method allows the application to reassociate an unmodified object with a new session."
With some samples like
//just reassociate:
sess.lock(fritz, LockMode.NONE);
//do a version check, then reassociate:
sess.lock(izi, LockMode.READ);
//do a version check, using SELECT ... FOR UPDATE, then reassociate:
sess.lock(pk, LockMode.UPGRADE);
In JavaDoc API "lock" is described as
"Obtain the specified lock level upon the given object. This may be used to perform a version check (LockMode.READ), to upgrade to a pessimistic lock (LockMode.UPGRADE), or to simply reassociate a transient instance with a session (LockMode.NONE)."

Does the "lock" throws a exception in case of a stale (modified) Object?
this meand Hibernate internally does a "SELECT" down to the data-
base? And what about the following:
"Hibernate will always use the locking mechanism of the database, never lock objects in memory!" (Ref, Page#81)
Dows this part means explicitly the "lock()" function of a session?
What happens if i perform a Lock on two objects (diffrent types), having a Database like mySQL with very restricted Locking-support? Because on mysql you only can perform one LOCK statement at a time... hmm

Seems like i'm not understanding the right way to "do a lock and guaranteed update without risk of inpersistence in case of multiple application-access on multiple objects"

Is it really that complex? ;-)