exactly! > -----Urspr�ngliche Nachricht----- > Von: Max Rydahl Andersen [mailto:[EMAIL PROTECTED]] > Gesendet: Donnerstag, 12. September 2002 09:12 > An: OJB Users List > Betreff: Re: ODMG and locking > > > So - as long one does not have auto-retreive on the graph it > is not an issue > ? > > /max > > ----- Original Message ----- > From: "Mahler Thomas" <[EMAIL PROTECTED]> > To: "'OJB Users List'" <[EMAIL PROTECTED]> > Sent: Wednesday, September 11, 2002 9:27 AM > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
