Re: Hibernate don't manage locks bewtween several JVMs...
Hi Brian, I like that idea! It would put an end to that discussion. Thomas Brian McCallister wrote: It may be worthwhile to have database-lock pessimistic locking as a clearly labeled option (non-default) in order to cut short these periodic discussions =) I'd be all in favor of bundling a DatabaseLockManager along with the current implementations. A fair number of people prefer this behavior. -Brian On May 10, 2004, at 3:21 PM, Thomas Mahler wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hibernate don't manage locks bewtween several JVMs...
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]
Re: Hibernate don't manage locks bewtween several JVMs...
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] ___ ... and the winner is... WEB.DE FreeMail! - Deutschlands beste E-Mail ist zum 39. Mal Testsieger (PC Praxis 03/04) http://f.web.de/?mc=021191 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hibernate don't manage locks bewtween several JVMs...
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]
Re: Hibernate don't manage locks bewtween several JVMs...
It may be worthwhile to have database-lock pessimistic locking as a clearly labeled option (non-default) in order to cut short these periodic discussions =) I'd be all in favor of bundling a DatabaseLockManager along with the current implementations. A fair number of people prefer this behavior. -Brian On May 10, 2004, at 3:21 PM, Thomas Mahler wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hibernate don't manage locks bewtween several JVMs...
I have gotten a great deal of value out of this thread. I am a novice OJB user compared to all of you but find OJB to be pretty darn good and well thought out. Hibernate seems to have a lot of PR and attention. But that doesn't make it the best choice. What I would like to do is have a non-emotional, factual comparison between the two as a way of helping me explain the differences and helping other choose OJB. I found Thomas's explaination great. Good explaination of the issue and why OJB took the direction that it did. And how the plugable design allows the configuration of different behaviours. BRAVO! Good Design and Architecture. Big Point from me on that. Shameless, Plea: Getting an OJB / Spring Framework module would be very forward thinking. I believe the Spring will continue to grow in popularity. Seems like a GREAT combination. Quoting Brian McCallister [EMAIL PROTECTED]: It may be worthwhile to have database-lock pessimistic locking as a clearly labeled option (non-default) in order to cut short these periodic discussions =) I'd be all in favor of bundling a DatabaseLockManager along with the current implementations. A fair number of people prefer this behavior. -Brian On May 10, 2004, at 3:21 PM, Thomas Mahler wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
