[jbosscache-dev] JBoss Cache 2.0.0.ALPHA status

[Brian Stansberry]

A different problem is that all the remove() and put() calls won't be
transactional on the far cache unless you're able to use a distributed
transaction manager.

jbosscache-dev-bounces at lists.jboss.org wrote:
> Thought about it a bit more, and I don't think it has that problem.
> 
> If the remote cache is being used as a cacheloader, it should
> have no existence other than for that purpose. So, a store
> call should feel free to completely replace the subtree being stored.
> 
> Therefore, the first step of the state transfer store should
> be to recursively remove all nodes for the given subtree in
> the remote cache.
> Thereafter there are no problems with leftover data.
> 
> Vladimir Blagojevic wrote:
>> This approach would be a very nice and generic solution but as you
>> point it has a problem with integration/clearing of nodes.
>> 
>> Looks like we have to do something along the lines that Manik
>> suggested. I'll assign that task to myself.
>> 
>>> -----Original Message-----
>>> From: Brian Stansberry
>>> Sent: Monday, September 11, 2006 12:35 PM
>>> To: Vladimir Blagojevic; Manik Surtani;
>>> jbosscache-dev at lists.jboss.org Subject: RE: [jbosscache-dev] JBoss
>>> Cache 2.0.0.ALPHA status 
>>> 
>>> Vladimir Blagojevic wrote:
>>>> I made TcpCacheLoader test pass but tcpcacheloader will not
>>>> propagate load/store. This was the case even before I made the
>>>> cacheloader change. Similar situation is with rpc and rmi loaders
>>>> and we have to figure out what to do there.
>>> 
>>> In the case of store, is this a matter of reading out the NodeData
>>> objects and invoking a put(Fqn, Map) on the remote cache for each
>>> one? For load, a bunch of recursive get(Fqn) calls to create the
>>> NodeData? (I'm skipping any subtleties of the 2.0 API here.)
>>> 
>>> A problem with the put(Fqn, Map) approach is that call integrates
>>> the passed Map into the target node, rather than replacing the map
>>> contents.  So you could be left with stale key/value pairs in the
>>> far cache.
> 
> 
> 
> 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



Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry