db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: serialization of Derby DataSources
Date Fri, 21 Apr 2006 22:50:32 GMT


Rick Hillegas wrote:
> David W. Van Couvering wrote:
>
>> My understanding was that they may persist across upgrades because 
>> the data source objects are serialized into a JNDI store.  In general 
>> we can *add* non-transient fields but we can't remove or change them.
>
> Thanks for that warning about the JNDI store. It would be better if we 
> could flush the old object from the JNDI store.
>
> Sigh. According to an experiment I just ran, the de-serialization 
> silently fails to populate the added field with a meaningful value, 
> even if you specify a default in the field declaration or in a no-arg 
> constructor. The added field is forced to the Java default for that type.
>
> I think this is tricky enough to warrant comments in these classes.
if you add fields, you need to code it so that they get initialized to a 
reasonable value with when de-serialized using an older copy of the object.
>
> Thanks again,
> -Rick
>
>>
>> I think also since we support the Referenceable interface, the object 
>> is reconstructed in a compatible way using our own code, rather than 
>> depending upon serialization's default mechanism.  But that's where 
>> I'm still a little muddled.
>>
>> By the way, using the *exact* same compiler, I tried to gently modify 
>> a DataSource following all the rules I could imagine, and because I 
>> didn't know the serialVersionUID was accidentally made private, I 
>> kept getting an incompatible class error or whatever it's called.  I 
>> was doing everything perfectly, and it was still breaking.  Once I 
>> set the serialVersionUID to be public, peace reigned.
>>
>> David
>>
>> Rick Hillegas wrote:
>>
>>> Thanks, Lance. I agree. We seem to have a muddle if someone adds a 
>>> new non-transient field to one of these classes: either a) the 
>>> engineer changes the serialVersionUID, giving rise to the problem 
>>> you mention or b) the serialVersionUID isn't changed and 
>>> deserialization fails because the new field is missing from the 
>>> persisted stream. Hopefully we don't mean for these objects to 
>>> persist across Derby upgrades. Hard to tell from the code.
>>>
>>> Regards,
>>> -Rick
>>>
>>> Lance J. Andersen wrote:
>>>
>>>> Hi Rick,
>>>>
>>>> once the serialVerisonUID is there, you should not remove it as 
>>>> chaos can break out if the IDs start to differ. IMHO would leave 
>>>> them alone.
>>>>
>>>> One example is you have say someone using say derby version x with 
>>>> a an ID of 1 and then persisted the object... now u remove the ID 
>>>> in derby y and the compiler generates say -2 for the ID , you will 
>>>> encounter problems when you try and grab the persisted version as 
>>>> the IDs no longer match.
>>>>
>>>>
>>>>
>>>> Rick Hillegas wrote:
>>>>
>>>>> Thanks, David. I'm afraid I'm still muddled. I think I understand 
>>>>> the basic purpose of serialVersionUID: It's a compiler-generated 
>>>>> checksum of the source which serialization uses as a sanity check. 
>>>>> By explicitly setting this field, the engineer promises to keep 
>>>>> the following contract: Although the class behavior may change 
>>>>> between versions, the  non-transient fields won't.
>>>>>
>>>>> But I'm still not grasping the serialization issue we're 
>>>>> addressing here. How do we get into a situation where there are 
>>>>> two different versions of one of these classes? Is anyone 
>>>>> persisting these classes across upgrades of the Derby code?
>>>>>
>>>>> Perhaps all that's being addressed here is the following 
>>>>> recommendation from the javadoc of java.io.Serializable: "However, 
>>>>> it is /strongly recommended/ that all serializable classes 
>>>>> explicitly declare serialVersionUID values, since the default 
>>>>> serialVersionUID computation is highly sensitive to class details 
>>>>> that may vary depending on compiler implementations..." I don't 
>>>>> think we have this problem, though: at release time we produce a 
>>>>> standard, vetted version of Derby for which the compiler is constant.
>>>>>
>>>>> Thanks for helping me puzzle through this.
>>>>>
>>>>> Regards,
>>>>> -Rick
>>>>>
>>>>> David W. Van Couvering wrote:
>>>>>
>>>>>> I had to look into this when I was playing around with a 
>>>>>> classloader for code sharing.
>>>>>>
>>>>>> Basically, by setting the serialVersionUID, you are telling the 
>>>>>> VM that you guarantee that the newer version of the class is 
>>>>>> compatible with the old version (in terms of serialization).
>>>>>>
>>>>>> If you don't set this, then you will get an exception saying the

>>>>>> class is not compatible if the VM determines that version UID 
>>>>>> (basically a hash) is different.  There is documentation 
>>>>>> explaining how this UID is determined, and I struggled to get it

>>>>>> right, but finally I had to set the serialVersionUID.
>>>>>>
>>>>>> Note that you have to set the serial version UID on the *second*

>>>>>> and subsequent versions of the class, it's not required for the 
>>>>>> first version of the class.  Basically, you run serialver on the

>>>>>> first version of the class, and then use this to set 
>>>>>> serialVersionUID in the second version.
>>>>>>
>>>>>> I wrote some tests to verify serialization compatibility between

>>>>>> versions of classes but never got to the point of checking them 
>>>>>> in. They may be valuable, and could be added to our compatibility

>>>>>> tests, so if you'd like I can poke around and find them.
>>>>>>
>>>>>> One bug I uncovered in my tests was that for one of the data 
>>>>>> sources the serialversion UID was not public, so I was getting 
>>>>>> failures.  Now I can't remember if I checked in that fix or not.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> Rick Hillegas wrote:
>>>>>>
>>>>>>> I'm confused about the presence of serialVersionUIDs in the 
>>>>>>> DataSources exposed by our network client (e.g., 
>>>>>>> ClientConnectionPoolDataSource). I think I understand why these

>>>>>>> classes are serializable (JNDI wants to serialize them). But
I 
>>>>>>> don't understand why we are forcibly setting the serialization

>>>>>>> id. I don't see any documentation explaining the serialization

>>>>>>> problem this addresses, stating the implications for engineers

>>>>>>> editting these classes, or describing our expectations at 
>>>>>>> version upgrade.
>>>>>>>
>>>>>>> Can someone shed some light on this?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Rick
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>

Mime
View raw message