I would personally much rather have the ability to turn off implicit locking of related objects; I don't want any objects to be accidentaly modified and saved.
Cheers, Charles. >-----Original Message----- >From: Matthew Baird [mailto:[EMAIL PROTECTED]] >Sent: 12 September 2002 00:04 >To: OJB Users List >Subject: RE: ODMG and locking > > >repost: > >So regarding Collection Proxy Locking, I think there is a >reasonable solution: > >1. Maintain a list of information about Collections that are >locked as proxies, in this list put: > a. A query that will return the list of id's for >objects that are locked, ie > "SELECT ... FROM FOO_TABLE WHERE PARENT_ID = >BAR", decompose this from string based representation for >better performance. >2. During the locking phase of an object, do the following: > a. Check if the CollectionProxyLockedList has any elements > b. Check if the CollectionProxyLockedList has any >elements for this Table type (FOO_TABLE) > b. Check if the object being locked participates in the >many side of a one-to-many. > c. if there exists a locked collection on the table you >want to lock the object for, execute the query that checks if >this object is locked, ie > "SELECT COUNT(*) FROM FOO_TABLE WHERE PARENT_ID >IN <ALL PARENT ID's FOR COLLECTIONS MAPPED TO THIS TABLE THAT >HAVE PROXIED COLLECTIONS LOCKED> AND ID=<requested for lock object id>" > d. if result is not 0, there is a lock on that object. > >I think this should be reasonably fast if implemented >correctly, and could still be implemented to work with the >persistent lock map impl as well as the in-memory lock map. It >would depend on users knowing how their application works, and >then configuring proxied collections properly. > >thoughts? > > >-----Original Message----- >From: Mahler Thomas [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, September 11, 2002 12:27 AM >To: 'OJB Users List' >Subject: AW: ODMG and locking > > >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]>
