The OJB LockManager manages concurrency between several Threads and between several applications/JVM too!
To realise that, it uses extra table in database.

I know that hibernate manages concurrency between Threads but what about different JVMs? can hibernet do the same thing? If yes, how to use it? Does it uses extra tables too?

Thanks

This is a very bad design, exposing your application to a single bottleneck. Hibernate never locks across threads, this is the job of the database: Read the documentation about LockMode and pessimistic database locks. Hibernate has a very "optimistic" concurrency control model, using version checks.

I agree that it's database's role to manage concurrency accesses but relationnals databases are not able to manage objects coherence/integrity. It should be done with the ORM which as an "object" view of the database, isn't it?

So, this kind of lock is indeed better with distributed or client/server applications with a single centralized instance of the ORM, but what about other applications?

Should all object applications with persistence be distributed?
If the answer is yes for design reasons, sometimes it's not possible to make big structural changes on existing applications for technial or economic/time reasons (my case)...

I don't understand you, but locks should certainly not be held by the application tier.

Sorry, my english is probably not good enough :( (i'm french ;)).
If locks should not be held by the application tier, why OJB permit that?

I don't know. Hibernate also uses locking in the application tier, but only for the (optional) second-level distributed cache.

I thought they have emoved this "feature", I do not think somebody uses it in practice. It is more easy to break concurency contorl than to implement it, I am not sure about OJB, but this is one of way to break concurency contorl, It sometimes used as workaround to avoid dealocks.
I do not recommend it, but this way can be used if you have very big problems with dealocks in production :
Create fake table, lock this table as the first operation of any transaction (connection wrapper can do it). Transactions become serial, all deadlocks will be eliminated, concurent execution is broken, but you will have time to test application and to find problems before to dissable this workaround.

Ok thanks to christian and baliukas. I will may be back :)

As promised, I'm back :)

If i understood well, using optimistic locking requires an extra "version" or "timestamp" column in each concerned table in the database.
So, the locking information is stored in the database and is not JVM dependant --> and so, using optimistic locking permits to manage concurrency between several JVMs. Am i wrong?

You are right. Make sure you understand the implications: Pessimistic locking is "user gets an error message because someone else is already editing that object" while optimistic is "user gets an error message when he saves his changes, because someone has modified the object meanwhile".

Optimistic concurrency is essential for high performance in multi-user environments.

First, i want to thank you for your usual short answer time, it's very pleasant ;)

Yes i understood the implications.

I would like to be sure that the SGBD don't espacially have to support any "optimistic locking notion"... we can create a "version" column manually which name is specified in the xml mapping file; and only hibernate will update this field (not the database).

Other thing: Does the optimistic locking works fine with objects associations in general and tree structures in particular?

Hibernate will increment the version whenever an object is dirty and saved, that is, whenever a property (even collections) are modified. I'm working on a more flexible configuration for that, but this is the current behavior.