[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