Hi, According to
http://jakarta.apache.org/ojb/lockmanager.html 'The ODMG specification does not say if locks must be acquired explicitely by client applications or may be acquired implicitely'. From this, I guess not. Cheers, Charles. >-----Original Message----- >From: Phil Warrick [mailto:[EMAIL PROTECTED]] >Sent: 11 September 2002 14:31 >To: OJB Users List >Subject: Re: AW: ODMG and locking > > >Hi Thomas & Charles, > >Would using this flag violate the standard ODMG behaviour for locking? > >Thanks, > >Phil > >Mahler Thomas wrote: > >> Hi Phil, >> >> As Charles already mentioned this is a known issue. >> The solution we have in mind is to provide a flag that will >allow you to use >> explicit locking, without scanning of object graphs etc. >> >> This is the next thing I'm going to implement. I hope to get >it done within >> a the next 2 weeks. >> >> thanks for your patience, >> Thomas >> >> >> >>>-----Urspr�ngliche Nachricht----- >>>Von: Phil Warrick [mailto:[EMAIL PROTECTED]] >>>Gesendet: Dienstag, 10. September 2002 18:25 >>>An: OJB Users List >>>Betreff: ODMG and locking >>> >>> >>>Hello, >>> >>>I've run into the problem of ODMG locking overhead and would >>>like some >>>ideas about best OJB practices to deal with it (~4 minutes to >>>retrieve >>>one object means something has to be done). I've seen bits >>>and pieces >>>of discussion related to this issue, so forgive me if I'm >bringing up >>>old stuff. >>> >>>If I understand correctly, enforcing persistence by >>>reachability means >>>that once one object is retrieved, this object and all others in the >>>associated graph are locked. >>> >>>Does the locking extend to the contents of proxy references >and proxy >>>collections? >>> >>>What are the best ways to limit the extent of the locking in a large >>>graph? For example, say some classes have instances that are >>>created/updated often and these classes refers to other >>>classes that are >>>much more static. If the graph of the static objects is >>>large, locking >>>is a big problem. How can one keep the link between these >>>classes and >>>not suffer the lock overhead? >>> >>>Your responses would be most appreciated. >>> >>>Phil >>> >>> >>>-- >>>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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
