[jbosscache-dev] Stream dilemma

[Vladimir Blagojevic]

So basically the contract with object based streams obliges cacheloader
implementors as following:

- they are not allowed to close the stream
- they should not catch any exceptions
- they should not wrap the provided object stream

And it gives us (state transfer generators/integrators) all the
flexibility we need:

- we keep control of which stream we pass
- we keep the reference to the passed stream
- we keep control of stream closing and exception handling

If this contract is violated we lose interoperability between various
cacheloaders, cacheloader implementations are very error prone and it
becomes very hard for state transfer generators/integrators to correctly
implement state transfers.

  

> -----Original Message-----
> From: jbosscache-dev-bounces at lists.jboss.org 
> [mailto:jbosscache-dev-bounces at lists.jboss.org] On Behalf Of 
> Vladimir Blagojevic
> Sent: Monday, August 28, 2006 10:40 AM
> To: jbosscache-dev at lists.jboss.org
> Subject: [jbosscache-dev] Stream dilemma
> 
> 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
> 
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>