Hi Max, I came to the same conclusion as Jason.
I am aware of the risk using ODMG locks. We have found that when using a services architecture though, we know at the beginning of a transaction whether we want to update an object or whether we just want to read it. We use committed reads and never updgrade a read lock to a write lock half way through the transaction. We defined a "readForUpdate" method in our superclass session bean which immediately attempts to obtain a write lock. In order to reduce the overheads of excessive lock propagation we also kept our containment hierarchies fairly shallow through the careful use of foreign keys here and there. Interestingly enough, as non-oo as it mights seem, this practise enforced a nice "vertical" decoupling, and kept our inter-package dependencies low. We used mediators to manage the foreign key dependencies. The other problem that was referred to on this list, was the 'new' object confusion when an object is deleted from another thread. Since our system has to be auditable and has to support historic reports, we are not allowed to delete objects. We just "deactivate" them (users never see deactivated objects). It solved any cascaded delete issues too. I realise the risk is still there that there might be resource contention between those two lines of code in "readForUpdate" where I read and lock the object, but I plan to have quite a few unit tests which I will run from separate threads to assess this risk. Understand that I am not prescribing an architecture, I am simply describing ours. I would really appreciate any corrections if there is a flaw in my reasoning. Regards Ampie. -----Original Message----- From: Max Rydahl Andersen [mailto:[EMAIL PROTECTED]] Sent: 12 October 2002 07:53 To: OJB Users List Subject: Re: Thanks Thomas May I ask (again) how you circumvent the problems about having just one global cache ? Are you using ODMG locks ? Or are you just crossing your fingers :) (note: this is not in any way a question to put OJB down, im just curious on how people gets by without the guarantee for multiple threads not stepping each others toes in OJB when not using ODMG) /max ----- Original Message ----- From: "Jason Mihalick" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Saturday, October 12, 2002 6:46 PM Subject: Thanks Thomas Just wanted to thank you for your help in answering questions as rapidly as you have. I'm happy to let you know that we will be (and already have been) using OJB for our application slated to be in production about end of Q3 2003. It was a tough choice between Hibernate and OJB, but our team felt that OJB was the best option for us because of the standards based approach it is taking, the dedication that the developers appear to have to the project, the ease of use of the PersistenceBroker API, and how well OJB is working with our database design thus far. Looking forward to more correspondence with you. Thanks, Jason -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
