[jbosscache-dev] Re: Integrating steaming transfer in JBC

[Brian Stansberry]

Bela Ban wrote:
> Brian Stansberry wrote:
>> Really, the whole idea is to make the byte[] go away
>> -- it serves no purpose, and once its created most (probably all) of
>> the benefit of streaming state transfer is lost.
> 
> I think streaming state transfer should be an *additional mechanism*,
> *not* replace the byte[] approach. The byte[] approach is
> certainly simpler, so for small to medium states, developers
> may not want to use the (somewhat more complex) streaming
> approach. Compare this to the XML pasring modeL DOM is the
> byte[] model, Stax/SAX are the streaminmg state model.
>

+1.  What I meant there was *if you are using streaming*, you don't want
the byte[].
 
>> As you say the tricky part is how does the cache loader know the
>> boundaries of what to read? Probably the simplest solution is the
>> StateTransferGenerator ensures the persistent state is the last stuff
>> written; the receiving cache loader then just reads until there is no
>> more.
> 
> The format has been defined and - if needed - should be
> defined again, so that different CacheLoaders can transfer
> state betwen each other, e.g. JDBCCacheLoader with
> JDBMCacheLoader. I suspect we also have to include the
> version numbers in this format...

Ah, so we'd actually have a specified format for persistent state, as
opposed to the current case where all the impls we write share a format,
but it's not specified. Cool :)

<snip>

>> Hmm. Perhaps the CacheLoader API needs to use
>> ObjectInput/OutputStream. 
> 
> I think Input/OutputStream is good enough, you can always
> wrap it with an OIS/OOS

I was thinking there might be an issue with this:

1) StateTransferIntegrator gets InputStream IS from the JGroups layer.
2) Uses it to create ObjectInputStream OIS#1.  Uses that to read off the
in-memory state and any marker we insert in the stream.
3) Closes OIS#1.
4) Passes IS to the cache loader.
5) Cacheloader creates ObjectInputStream OIS#2 from IS.  Reads the
persistent state.

Maybe that will work fine; it would be good if it did as it allows for a
more flexible API.