Pinaki, On 10/8/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote: > > Hi Craig/Kevin, > Assertion 1. One of the critical reasons of proxying SCO is to dirty the > StateManger corresponding to its owner. > Assertion 2. This dirty-propagation must be active in remote clients > i.e. in a detached mode as well, if the user configures it so. > > From the above, the actual instance of the SCO that is in the detached > client must refer to the StateManager of its owning instance. > That is where my doubt of Kevin's proposed change of nullfying the > StateManager reference in cloning the SCO Proxy and treating the cloned > instance as the detached copy of the SCO that the client sees. > > At least that is what I had interpreted of Kevin's suggested change. > Correct me if I am wrong.
Nope, not for this reason. Or is it just that no OpenJPA code ever calls Proxy.clone(), but is > still overwritten because some JVM may clone a Calendar instance for > unexplained reasons? This is the reason for the change. I can put comments in the clone() generation code to indicate the reasons for this method. I would not expect OpenJPA to use this clone() method. Btw, Proxy.copy() is used to keep a copy for restore upon rollback. Correct. Thanks, Kevin Pinaki Poddar > 972.834.2865 > > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >Sent: Monday, October 08, 2007 1:48 PM > >To: [email protected] > >Subject: Re: [jira] Commented: (OPENJPA-396) Cloning Calendar > >proxies doesn't detach from StateManager > > > >Hi Pinaki, > > > >On Oct 8, 2007, at 11:35 AM, Pinaki Poddar wrote: > > > >>> I am proposing to modify > >>> the generated proxy code to override the clone() method. This > >>> clone() method will do the necessary copying of data from the > >>> original object, but then also null out the sm (StateManager) and > >>> zero out the field attributes. This action detaches the cloned > >>> object from the StateManager (and associated EntityManager). > >> > >> Who will invoke this Proxy.clone()? and when? > >> > >This is mostly from memory. If I get it too wrong, then you > >can take all of my comments on this as a whiff of fresh air. > > > >> Are we now having > >> A) the original user object x > > > >No, if you fetch an instance from the database with a field of > >type Calendar, all you get is a proxy. > > > >> B) the proxy of x > > > >Yup, this is the value of the field. > > > >> C) clone of proxy of x > > > >If you clone the proxy, you get a clone. Which should not have > >anything to do with the original proxy. > > > >> D) copy of proxy of x, as generated by Proxy.copy() > > > >I don't know of any use for this. > >> > >> If the clone with no owning statemanager is the 'detached' SCO, then > >> how will the change in SCO be tracked in remote client? > > > >The bug refers to a strange usage of clone by the IBM VM. ;-) > > > >The clone with no owning statemanager should never be the > >value of any field, whether attached or detached. If a clone > >is set as the value of a field, then the enhanced putfield > >method should assign ownership of that clone to the > >statemanager of the instance whose field is being set. And > >then the clone is no longer a clone but a bona fide proxy that > >has an owner. > > > >Craig > >> > >> Pinaki Poddar > >> 972.834.2865 > >> > >> > >>> -----Original Message----- > >>> From: Kevin Sutter (JIRA) [mailto:[EMAIL PROTECTED] > >>> Sent: Monday, October 08, 2007 12:54 PM > >>> To: [email protected] > >>> Subject: [jira] Commented: (OPENJPA-396) Cloning Calendar proxies > >>> doesn't detach from StateManager > >>> > >>> > >>> [ > >>> https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atla > >>> ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action > >>> _12533169 ] > >>> > >>> Kevin Sutter commented on OPENJPA-396: > >>> -------------------------------------- > >>> > >>> [ Show > ] > >>> Craig Russell - 08/Oct/07 10:25 AM Hi Kevin, One question. In the > >>> generated clone method, after calling super.clone(), why do you not > >>> simply invoke stateManager = null; pcState = 0; instead of calling > >>> the setOwner(null, 0) method? Seems like there is > >additional code in > >>> setOwner that you want to avoid because there is not yet any > >>> relationship between the owner and the sco. The effect of calling > >>> this method from the clone might be to disassociate the > >original sco. > >>> > >>> Craig, > >>> The original reason is that I couldn't figure out the proper serp > >>> invocations to just set those two fields. :-) Then, I found the > >>> setOwner method on the Proxy (also generated code) that did > >just what > >>> I was looking for. So, it was more straight-forward to just call > >>> this method than to repeat the same code. > >>> > >>> As far as I can tell, the setOwner has no other side effects. > >>> I am calling setOwner on the Proxy, not the StateManager. The code > >>> is generated in the ProxyManagerImpl class (addProxyMethods > >method). > >>> And, the javadoc for this method is as follows: > >>> > >>> /** > >>> * Reset the state of the proxy, and set the owning instance of > >>> the > >>> * proxy and the name of the field it is assigned to. > >Set to null > >>> to > >>> * indicate that the proxy is no longer managed. > >>> */ > >>> public void setOwner(OpenJPAStateManager sm, int field); > >>> > >>> Kevin > >>> > >>> > >>>> Cloning Calendar proxies doesn't detach from StateManager > >>>> --------------------------------------------------------- > >>>> > >>>> Key: OPENJPA-396 > >>>> URL: > >>> https://issues.apache.org/jira/browse/OPENJPA-396 > >>>> Project: OpenJPA > >>>> Issue Type: Bug > >>>> Components: kernel > >>>> Affects Versions: 1.0.0, 1.0.1, 1.1.0 > >>>> Reporter: Kevin Sutter > >>>> Assignee: Kevin Sutter > >>>> Fix For: 1.0.1, 1.1.0 > >>>> > >>>> Attachments: OPENJPA-396.patch > >>>> > >>>> > >>>> This problem was first discussed on our dev mailing list: > >>>> http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html > >>>> Per the discussion on that thread, I am proposing to modify > >>> the generated proxy code to override the clone() method. This > >>> clone() method will do the necessary copying of data from the > >>> original object, but then also null out the sm (StateManager) and > >>> zero out the field attributes. This action detaches the cloned > >>> object from the StateManager (and associated EntityManager). > >>>> Instead of limiting this action to the Calendar proxy, I am > >>> adding the clone() method implementation to all of our > >proxy objects > >>> that we generate. Granted, some of the object types do not > >directly > >>> support the clone() method, but that will be detected when or if > >>> anybody attempts to use the clone() method on these types (compiler > >>> generated error message). > >>>> I'll be posting a patch shortly and I plan to commit the > >>> changes later today (unless there is opposition). > >>>> Thanks, > >>>> Kevin > >>> > >>> -- > >>> This message is automatically generated by JIRA. > >>> - > >>> You can reply to this email to add a comment to the issue online. > >>> > >>> > >> > >> Notice: This email message, together with any attachments, may > >> contain information of BEA Systems, Inc., its subsidiaries > >> and affiliated entities, that may be confidential, proprietary, > >> copyrighted and/or legally privileged, and is intended > >solely for the > >> use of the individual or entity named in this message. If > >you are not > >> the intended recipient, and have received this message in error, > >> please immediately return this by email and then delete it. > > > >Craig Russell > >Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > >408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! > > > > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual or > entity named in this message. If you are not the intended recipient, and > have received this message in error, please immediately return this by email > and then delete it. >
