[jbosscache-dev] Stream dilemma

[Vladimir Blagojevic]

Brian and I talked privately about changing CacheLoader API to use
object based stream parameters rather than plain input/output streams.
Please comment.

-----Original Message-----
From: Brian Stansberry 
Sent: Saturday, August 26, 2006 2:29 PM
To: Vladimir Blagojevic
Subject: RE: Stream dilemma

I much prefer the latter.  Earlier on a thread about this we determined
we wanted cross-CacheLoader interoperability and thus were going to
formally specify the format of the state as a sequence of serialized
NodeData objects.  Therefore by the interface contract the cache loader
must use an ObjectInput/OutputSteam to do its job; it's not like the
loader implementor has freedom to use some
com.xyz.CustomStateEncodingInput/OutputStream.  Given that, providing
the ObjectInput/OutputStream to the cache loader makes a lot more sense
for the reasons you stated.  The CacheLoader's job is simply to read the
objects and store them; it shouldn't have access to the stream
underlying the ObjectInput/OutputStream as providing that access limits
the flexibility of the StateTransferGenerator/Integrator.

Once you provide the ObjectInput/OutputStream, that also logically
implies that the overloaded methods with the byte[] should go away.
Either the CacheLoader has to know how to manage the lifecycle of an
ObjectInput/OutputStream or it doesn't.

Vladimir Blagojevic wrote:
> Hey Brian,
> 
> I am trying to find the best solution for persistent state 
> loading/storing and I want to bounce this off you.
> 
> Dilemma is whether to allow cacheloader implementers to create and 
> close the stream themselves in load/store cacheloader implementations 
> or not. If we keep current API signature with InputStream/OutputStream

> then cacheloader implementers have to wrap this stream with a variant 
> of ObjectInputStream/ObjectOutputStream and then if they create this 
> stream then they have to close it themselves. Which is fine I believe 
> because we write/read persistent state last in state transfer. We also

> have to rely on cacheloader implementers that they know what they are 
> doing. They might not for example propagate io exceptions to us and 
> thus we have no idea that something went wrong.
> 
> If we change current API signature to accept 
> ObjectInputStream/ObjectOutputStream then we sort of have more control

> about which stream we pass to cacheloader implementers (we have 
> reference to that stream), more control about closing it and we 
> require less intelligence from cacheloader implementers about dealing 
> with these streams.
> They simply read/write and do not catch any io exceptions and let 
> everything propagate to the caller.
> 
> I know I have not summarized this nicely. I am just sort of thinking 
> out loud.
> 
> All the best,
> Vladimir



Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry