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 > _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev