Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 21 Apr 2006 14:16:06 -0700
From: "David W. Van Couvering" <David.Vancouvering@Sun.COM>
Subject: Re: serialization of Derby DataSources
In-reply-to: <444941B5.5090401@sun.com>
To: derby-dev@db.apache.org
Message-id: <44494B96.6080005@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 1.5 (Windows/20051201)
References: <44490229.6020202@sun.com> <44492179.9040600@sun.com>
 <44492B63.4000609@sun.com> <44492E3C.4000205@sun.com>
 <444941B5.5090401@sun.com>

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.

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
>>>>
>>>>
>>>
>