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

[Galder Zamarreno]

This is precisely what we're discussing when I was pondering how to transfer in-memory state to the persistent one as part of the SingletonCacheLoader development.

+1

Galder Zamarreño
Support Engineer
JBoss, a division of RedHat


-----Original Message-----
From: jbosscache-dev-bounces at lists.jboss.org [mailto:jbosscache-dev-bounces at lists.jboss.org] On Behalf Of Brian Stansberry
Sent: 15 August 2006 22:16
To: Bela Ban
Cc: Manik Surtani; jbosscache-dev at lists.jboss.org
Subject: RE: [jbosscache-dev] Re: Integrating steaming transfer in JBC

I added a JIRA to add the format to the CacheLoader javadoc:
http://jira.jboss.com/jira/browse/JBCACHE-738

Bela Ban wrote:
> That's well defined (via NodeData), and I also wrote some
> document explaining the format.
> 
> Simple:
> - persistent state
> - marker
> - transient state
> - EOF
> 
> Brian Stansberry wrote:
>> Vladimir Blagojevic wrote:
>> 
>>> Is it not that whenever you close OIS#1 (as you do in step 3) close
>>> call is passed to underlying inputstream which would close actual
>>> tcp inputstream passed up by jgroups layer?
>>> 
>> 
>> Yep.
>> 
>> 
>>> We need some "end of in-memory state" marker?
>>> 
>>> 
>> 
>> Yes, definitely.  The in-memory state is a series of NodeData
>> objects, written one after another, not encapsulated in an array or
>> list or anything.  Persistent state is the same thing.  So you'd
>> need some sort of marker to tell the integrator when the in-memory
>> state is finished. 
>> 
>> 
>>>> 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.



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