> > > 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!
A simple example in our application, is an ActionGroup contains many ActionGroups and ActionTypes. An ActionType has many actions, many next ActionTypes, many ReallocationTypes, many Roletypes. I know that if I lock the ActionType object for write, 7 'SELECT COUNT(*)' statements are issued - currently the collections are empty i.e. there are no rows. If there was any data, there would be 7 SELECT columns blah balah to materialize the objects. I haven't try locking an ActionGroup for write yet, but I'm guessing there will be very many database queries. > > > > > > 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! As indeed you should be ! > 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 !!! Explanation and reasoning very clear; fully understand. > > > 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. No, you are missing nothing. My problem, then, is where to go from here. I need the Object Transactions provided by ODMG, but I *always* explictly lock objects for write i.e. I never assume they are locked because the "parent" is locked. I know this isn't how the ODMG is meant to be used, but there it is. I need lazy loading. It seems like the OTM layer may well have provided what I wanted, but it seems that this initiative has slowly trickled to a halt (Or maybe it hasn't, but there doesn't seem to have been much CVS activity on this). We cannot (currently) use DynamicProxies for our object references, since our domain model doesn't (and is unlikely) to support Interfaces for business objects (ain't my fault, shoot the analyst/designers). What I have done/am doing, is creating a RelationshipHelper that will lazily load a named relationship e.g. RelationshipHelper.load(actionGroup, "parentGroup"), and I call that in the getParentGroup method of ActionGroup. This checks the PersistentField for the reference, and if it is null, loads it (using cut'n'paste code "re-use" from PersistenceBrokerImpl). In other words, I'm having to implement my own lazy-loading strategy for object references. I guess I can do the same for collections; it's far from ideal, but it looks like the only way forward. Comments and/or other suggestions *warmly* accepted ! 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]>
