db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: serialization of Derby DataSources
Date Fri, 21 Apr 2006 23:01:32 GMT
Right, can't you override the readObject method or whatever it's called? 
  (Sorry, too lazy to look up the javadoc)

I have some tests, Rick.  If you'd like I can send them to you. 
Alternately log a JIRA and I can attach the source to the JIRA.
Can't actually spend the time to fully implement and check in the tests 
right now, maybe later.

David
Lance J. Andersen wrote:
> 
> 
> 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