Serialization issue due to lazy-loading

[Stephane Bailliez <sb...@apache.org>]

I came across a slightly annoying issue a couple of minutes ago with 
iBatis/cglib.

For instance I'm serializing data over the network that have cglib 
instrumented classes (relations)

When lazyloading is enabled (default), it could seem obvious that it 
does not make sense to serialize your data. You could well have 
bazillions of objects, yet this is what lazy loading is all about 
preventing.

Yet it is not always true.
You may know, that your relationships are not in the form 1:bazillion 
but more like 1:4 (replace 4 by your favorite 'less than 10' number) 
with very lightweights objects .

To workaround this, you can AFAIK:

1) disable applicationw-wide lazy loading via <settings/> (big side-effect)

2) implements your own serialization mechanism (annoying)


At the moment I did (2), where I'm basically doing:

class Parent {
    transient ArrayList children = new ArrayList();
    ... serializable fields...

     ...

     private void writeObject(ObjectOutputStream out) throws IOException {
         out.defaultWriteObject();
         ArrayList list = new ArrayList(children);
         out.writeObject(list);
     }

     private void readObject(ObjectInputStream in) throws 
ClassNotFoundException, IOException {
         in.defaultReadObject();
         children = (ArrayList)in.readObject();
     }
}


Yet, I was wondering if it would make sense to fine-grained control over 
the lazy-loading. For instance, having a per-statement lazy-loading flag 
where dependent requests (like in the case of n+1 selects) would inherit 
this flag.

Just some thoughts straight without thinking too much.
Any comments ?


Stéphane

Re: Serialization issue due to lazy-loading

[Stephane Bailliez <sb...@apache.org>]

Clinton Begin wrote:
> 
> Yes, finer grained control would be a great thing.   I don't believe 
> there's a JIRA request for it yet.
> 
> Could you please create one Stephane?
> 

Done

http://issues.apache.org/jira/browse/IBATIS-161

Cheers,

Stephane

Re: Serialization issue due to lazy-loading

[Clinton Begin <cl...@gmail.com>]

Yes, finer grained control would be a great thing. I don't believe there's a 
JIRA request for it yet.

Could you please create one Stephane?

Clinton

On 6/21/05, Stephane Bailliez <sb...@apache.org> wrote:
> 
> 
> I came across a slightly annoying issue a couple of minutes ago with
> iBatis/cglib.
> 
> For instance I'm serializing data over the network that have cglib
> instrumented classes (relations)
> 
> When lazyloading is enabled (default), it could seem obvious that it
> does not make sense to serialize your data. You could well have
> bazillions of objects, yet this is what lazy loading is all about
> preventing.
> 
> Yet it is not always true.
> You may know, that your relationships are not in the form 1:bazillion
> but more like 1:4 (replace 4 by your favorite 'less than 10' number)
> with very lightweights objects .
> 
> To workaround this, you can AFAIK:
> 
> 1) disable applicationw-wide lazy loading via <settings/> (big 
> side-effect)
> 
> 2) implements your own serialization mechanism (annoying)
> 
> 
> At the moment I did (2), where I'm basically doing:
> 
> class Parent {
> transient ArrayList children = new ArrayList();
> ... serializable fields...
> 
> ...
> 
> private void writeObject(ObjectOutputStream out) throws IOException {
> out.defaultWriteObject();
> ArrayList list = new ArrayList(children);
> out.writeObject(list);
> }
> 
> private void readObject(ObjectInputStream in) throws
> ClassNotFoundException, IOException {
> in.defaultReadObject();
> children = (ArrayList)in.readObject();
> }
> }
> 
> 
> Yet, I was wondering if it would make sense to fine-grained control over
> the lazy-loading. For instance, having a per-statement lazy-loading flag
> where dependent requests (like in the case of n+1 selects) would inherit
> this flag.
> 
> Just some thoughts straight without thinking too much.
> Any comments ?
> 
> 
> Stéphane
> 
>