db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Jefferson <a...@jpox.org>
Subject Re: Another api20 change
Date Mon, 27 Jun 2005 10:37:36 GMT
> 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 

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.

Java Persistent Objects - JPOX

View raw message