|
Home > Archive > Apache JDO Project > June 2005 > Another api20 change
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Another api20 change
|
|
| Michael Bouschen 2005-06-26, 5:45 pm |
| Hi,
attached you find some changes of the api20 project. It adds method
isDetached to the StateManager interface and add since tags to two PM
methods.
Regards Michael
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
| |
| Craig Russell 2005-06-26, 5:45 pm |
| | |
| Michael Bouschen 2005-06-26, 5:45 pm |
| Hi Craig,
thanks!
One more question: does the enhancer generated method jdoGetVersion
delegate to the StateManager? I think it should, so I propose I add the
following method to the StateManager:
/** Return the object representing the version of the calling instance.
* @param pc the calling <code>PersistenceCapable</code> instance
* @return the object representing the version of the calling instance.
*/
Object getVersion (PersistenceCapable pc);
What do you think?
Regards Michael
> Hi Michael,
>
> Looks good to check in.
>
> Craig
>
> On Jun 26, 2005, at 1:55 PM, Michael Bouschen wrote:
>
>
> 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!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
| |
| Andy Jefferson 2005-06-27, 2:45 am |
| > attached you find some changes of the api20 project. It adds method
> isDetached to the StateManager interface and add since tags to two PM
> methods.
Hi Michael,
when an object is detached it doesn't have a StateManager, hence the
jdoIsDirty() method added to PC instances during enhancement is typically
based on whether it has an objectId and state manager in the instance. Hence
my question is, why do we need this method ?
--
Andy
Java Persistent Objects - JPOX
| |
| Andy Jefferson 2005-06-27, 2:45 am |
| > when an object is detached it doesn't have a StateManager, hence the
> jdoIsDirty() method added to PC instances during enhancement is typically
> based on whether it has an objectId and state manager in the instance.
> Hence my question is, why do we need this method ?
I did of course mean to say "the jdoIsDetached() method".
--
Andy
Java Persistent Objects - JPOX
| |
| Michael Bouschen 2005-06-27, 7:45 am |
| Hi Andy,
this is just for JDO implementations that decide to keep the
StateManager for detached instances. The enhancer generated code for
jdoIsDetached needs to check whether there is a StateManager anyway. If
so it should delegate to it, if not it should check for the objectId.
What do you think?
Regards Michael
>
>
> I did of course mean to say "the jdoIsDetached() method".
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
| |
| Andy Jefferson 2005-06-27, 7:45 am |
| > this is just for JDO implementations that decide to keep the
> StateManager for detached instances. The enhancer generated code for
> jdoIsDetached needs to check whether there is a StateManager anyway. If
> so it should delegate to it, if not it should check for the objectId.
> What do you think?
Hi Michael,
Well I've no particular problem with the idea, but I seem to have missed the
discussion in the EG that we are even allowing StateManagers for detached
instances.
Some time back when we were discussing serialisation of detacheds I seem to
remember that it was decided not to have this. Maybe I misunderstood what was
being discussed.
What happens if someone passes a detached instance (that has no SM) across to
a JDO impl that needs a SM while detached ? What is the detached SM doing ?
(presumably keeping some track of what fields have changed - even though we
already have these fields stored in the BitSet).
What if JDO Impl 1 requires a StateManager while detached, and then the
detached instance is serialised. It is then passed to another app server and
the user tries to deserialise it. It is presumably going to try to
deserialise the SM, but JDO Impl1 classes aren't present on this app server.
If a detached instance can sometimes have a StateManager (dependent on the
implementation) then the spec should state that it is for the implementation
to decide whether to use them whilst detached. I don't see this currently.
--
Andy
Java Persistent Objects - JPOX
| |
| Michael Bouschen 2005-06-27, 5:45 pm |
| Hi Andy,
good question! I will not check in the StateManager changes before this
has been resolved. I hope that Craig can clarify.
Regards Michael
>
>
> Hi Michael,
>
> Well I've no particular problem with the idea, but I seem to have missed the
> discussion in the EG that we are even allowing StateManagers for detached
> instances.
>
>
> Some time back when we were discussing serialisation of detacheds I seem to
> remember that it was decided not to have this. Maybe I misunderstood what was
> being discussed.
>
> What happens if someone passes a detached instance (that has no SM) across to
> a JDO impl that needs a SM while detached ? What is the detached SM doing ?
> (presumably keeping some track of what fields have changed - even though we
> already have these fields stored in the BitSet).
> What if JDO Impl 1 requires a StateManager while detached, and then the
> detached instance is serialised. It is then passed to another app server and
> the user tries to deserialise it. It is presumably going to try to
> deserialise the SM, but JDO Impl1 classes aren't present on this app server.
>
> If a detached instance can sometimes have a StateManager (dependent on the
> implementation) then the spec should state that it is for the implementation
> to decide whether to use them whilst detached. I don't see this currently.
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
|
|
|
|
|