[jbosscache-dev] Stream dilemma

[Manik Surtani]

Yes, this sounds good.  Make sure the Cache Loader interface is  
appropriately javadoc'd to this effect though, so implementors  
satisfy the contract - especially the implicit parts about not  
closing the stream, not catching exceptions, etc.
--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani


On 28 Aug 2006, at 15:58, Vladimir Blagojevic wrote:

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