RE: [jbosscache-dev] Stream dilemma
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(a)lists.jboss.org
[mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
Vladimir Blagojevic
Sent: Monday, August 28, 2006 10:40 AM
To: jbosscache-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev