> 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
