AFAIK no! The ODMG spec does not mention if implementations should use implicit or explicit locking.
> -----Urspr�ngliche Nachricht----- > Von: Phil Warrick [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 11. September 2002 15:31 > An: OJB Users List > Betreff: 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
