openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: [jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't detach from StateManager
Date Mon, 08 Oct 2007 19:51:04 GMT
Pinaki,

On 10/8/07, Pinaki Poddar <ppoddar@bea.com> 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: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> >Sent: Monday, October 08, 2007 1:48 PM
> >To: dev@openjpa.apache.org
> >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:jira@apache.org]
> >>> Sent: Monday, October 08, 2007 12:54 PM
> >>> To: dev@openjpa.apache.org
> >>> 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:Craig.Russell@sun.com 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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message