RE: [jbosscache-dev] Re: Integrating steaming transfer in JBC
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.