directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@apache.org>
Subject Re: Serialization/deserialization questions
Date Fri, 25 Feb 2011 15:39:06 GMT
On 2/25/11 2:57 PM, Alex Karasulu wrote:
> On Fri, Feb 25, 2011 at 2:22 PM, Emmanuel Lecharny<elecharny@gmail.com>  wrote:
>> Hi guys,
>>
>> I'm reworking all the serializations for the base objects we are
>> manipulating. I have a few questions and I'd like to get you opinion.
>>
>> The base idea is to get rid of all the Externalizable/Serializable
>> interfaces, and to provide our own helper classes to serialize the objects
>> we have to write down the disk. The rationnal is that we avoid the cost of
>> writing the useless java class informations, keeping the written objects as
>> small as possible, and the process as fast as possible.
> Could you provide some of the problems that you encountered due to the
> use of the Externalizable/Serializable intefaces in some of these
> classes?

The main issue is the injection of the SchemaManager when we create the 
base object. readExternal() does not take any parameter, when using a 
helper class to do the same thing allows you to do so.
>> Q1 : Do we have to store a version number into the written data ?
> +1
>
>> Q2 : I'm going to inject the SchemaManager in all the deserialized data (it
>> can be null, if the SchemaManager has not been created). Do you think it's a
>> problem ?
> We can have separate serialization services that have a handle on the
> SchemaManager. These services can use schema information to handle
> their task of [de]serializing. However there are some entities that
> need access to schema information in order to conduct some operations
> like Entry.add( attribute ). How we handle access to schema
> information while they perform schema checks is another matter which
> we need to discuss.
>
> Perhaps a schema aware Entry wrapper can access this information
> leaving the simple Entry free to do as it likes while it intercepts
> calls and conducts schema live checks before delegating the call.
> Things like this can also be handled automatically with byte code
> manipulation. We can discuss this separately which would be involved.
What we need here is mainly to store the schemaManager, not to process 
the read data against the schemamanager. Doing so is a costly operation, 
and if we can avoid it, this is a net gain.

Also keep in mind that the serializations are mainly used inside the 
server, not anywhere else.
>> Q3 : In order to be able to create the object as it was when it was
>> serialized, I'll create package visible only constructors, with all the
>> needed parameters. Does it sounds the right approach ?
> This will require the [de]-serializer to be in the same package. That
> could present an issue with split packages if we want to make these
> entities into services down the line. I'd go ahead and make the
> constructors public for now.  Off the top of my head I cannot think of
> a detriment to exposing these constructors but perhaps you have some
> in mind?
Well, making those constructors public make the user think he can use 
them, when it's just intended to be used by the deserialization process. 
I don't think, OTOH, that having the deserializers along the class it 
works on is a big problem.

One other option would be to use a static method in the class to do the 
serialization/deserialization, and make the constructors private.


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message