Hi > > Hi, > Thought I'd repost this, as I really want to know what to do > about it....
Good idea, I forgot about your post... > Is > this issue a bug/feature or intentional ? > > Cheers, > > Charles. > > > -----Original Message----- > > From: Charles Anthony [mailto:[EMAIL PROTECTED]] > > Sent: 02 September 2002 09:22 > > > > Hi, > > > > In our repository, all our 1-many relations are > > CollectionProxies, with auto-retrieve=yes. > > > > Let's take a simple (hypotehtical) example of a Group with > > many Members. > > > > If we lock the "Group" for write, it seems that the contents > > CollectionProxy > > is materialized, and all the "Members" are locked for write as well. > > > > Our object graph is large; one object may have many > > collections. If we lock > > the parent object for write, we will get many queries > > executed (tip for the > > unaware : use the p6spy driver for excellent SQL logging) to > > lock the its > > many children. > > > > This, to my mind, is very innefficient. I agree! > > > > With dynamic proxies (for object references), the actual > > registering seems > > to be defered until materialization time (See TransactionImpl > > line 587 ish). correct. I'm very proud about this cool feature! > > > > > > This is a sort of question/request : > > Is this difference between CollectionProxies and > > DynamicProxies intended ? A Dynamic Proxy is a proxy for a single instance. Thus it is safe to use the deferred locking mechanism. Each tx that eventually tries to access the instance will use the same proxy instance and will trigger the deferred locking. A Collection proxy is a placeholder for many instances (say A, B, C). now we consider two transaction tx1 and tx2 tx1 loads a collection proxy for [A, B, C]. Now we do not materialze the proxy but we do set up a deferred Lock. now we assume that tx2 tries to obtain a lock on B. It will always succeed because there is no way to detect that tx1 already claimes an (implicit) lock on B !!! > > If it is, then what is the reasoning ? > > And if not, can I call this a bug , and ask for this deferring of > > registering also be applied to the CollectionProxy too ? I agree that this feature decreases performance. But I see no other way to avoid locking problems. Please correct me if I am missing something. cheers, Thomas > > > > Cheers, > > > > Charles. > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
