db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oyvind.Bakk...@Sun.COM
Subject Re: Backward compatibility of DataSource implementations
Date Wed, 23 Nov 2005 09:41:00 GMT
David W. Van Couvering wrote:
> In my ongoing investigation, it has become quickly obvious to me that 
> the various DataSource implementations we have must be serializeable so 
> they can be stored in a JNDI repository.

An excerpt from the javax.naming Description javadoc:


Objects are stored in naming and directory services in different ways. 
If an object store supports storing Java objects, it might support 
storing an object in its serialized form. However, some naming and 
directory services do not support the storing of Java objects. 
Furthermore, for some objects in the directory, Java programs are but 
one group of applications that access them. In this case, a serialized 
Java object might not be the most appropriate representation. JNDI 
defines a reference, represented by the Reference class, which contains 
information on how to construct a copy of the object. JNDI will attempt 
to turn references looked up from the directory into the Java objects 
they represent, so that JNDI clients have the illusion that what is 
stored in the directory are Java objects.

So, instead of trying to store a serialized java object, with all its 
inner gory details, I think it is better to let DataSource objects 
implement javax.naming.Referenceable and only store a Reference 
containing the required information for a JNDI client to create a 
DataSource object based on the information in the Reference. I think 
it's going to be easier to handle version skew using this rather than 
relying on serialization, you'll have more control. The logic you write 
for creating a DataSource object based on the information in a JDNC 
repository is independent of any internal fields you may have deleted 
from the class, etc.

> This means that they must maintain a strict level of compatibility so 
> that there are not serialization errors if the version of the class 
> stored in the JNDI repository is older than the version of the class in 
> the classloader of the client.
>  From the comments of ClientDataSource:
> - No deleting of fields
> - No changing of non-static to static or non-transient to transient, as 
> this is equivalent to deleting fields
> - No changing of field types within the class
> - Cannot alter the position of the class in the class hierarchy
> - Cannot change class name or package name
> Also, it appears we are making every effort to keep the size of these 
> objects reasonably small as they will in all likelihood be serialized 
> over the network from the JNDI repository to the client.
> Do I have that right?
> Thanks,
> David

Oyvind Bakksjo
Sun Microsystems, Database Technology Group
Trondheim, Norway

View raw message