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
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.
--
Michael Bouschen [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
