db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: Another api20 change
Date Mon, 27 Jun 2005 14:34:59 GMT
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		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			

Mime
View raw message