Hi NiX, Ojb provides several Locking strategies. You can use Optimistic locking based on versioning. Or you can use pessimistic locking. The pessimistic locking mechanism is implemented as a pluggable component. We ship two implementations: 1. an in-memory Lockmanager implementation that can be used if all transactions to manage reside in the same JVM. 2. a LockManagerServlet implementation that can be used if transactions across multiple JVMs must be coordinated.
Since RC5 this second solution does not require any additional database table. instead the LockServerServlet manages a large lock map in memory. This new solution is not yet documented properly... The discussion between the Hibernate and OJB teams about the pessimistic locking is rather old. Finally we came to a solution: we agree to disagree in this point. Hibernate folks seem to say pessimistic locking should be done in the database. They give their reasons in their replies to your mail. OJB die-hards tend to think that pessimistic locking belongs into the O/R layer. Here is why: 1. pessimistic locking is implemented differently by different database vendors. The DB2 concept of lock escalation (in case of lock-memory shortage the whole table gets locked) is unique. Oracle works different. So if we rely on DB managed locking the same application would behave differently if running against DB2 versus running against Oracle. 2. We think that Object level locking that is required by Object level transactionmanagement systems like JDO or ODMG can most efficiently be handled on the object level. If you place a lock on the root element of a large tree structure you'll have to traverse the whole tree and to lock each object contained in that tree. If object level locking in a JDO transaction have to be translated at runtime into database "locks for update" you'll have a lot of db calls for the locking stuff. With OJBs simple lock-hashtables this job is much faster. Because of our strong support for OODBMS APis like ODMG and JDO, OJB works more as an ObjectDatabase than a simple O/R mapper. 3. if you still think that locks should be kept in the DB, just go ahead. Simply write your own LockManager implementation class that uses database locks and plug it into OJB. I don't say the Hibernate answer is wrong. But IMHO the OJB answer is more complete and flexible. cheers, Thomas Can you give me your opinions about answers i was given on the hibernate forum: http://forum.hibernate.org/viewtopic.php?t=930648 Thanks -- -NiX- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _____________________________________________________________________ Der WEB.DE Virenschutz schuetzt Ihr Postfach vor dem Wurm Netsky.A-P! Kostenfrei fuer alle FreeMail Nutzer. http://f.web.de/?mc=021157 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
