[jbosscache-dev] JBoss Cache 2.0.0.ALPHA status

[Manik Surtani]

Exactly.
--
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 12 Sep 2006, at 07:42, Bela Ban wrote:

> Yes, correct. It can synthesize a fake GTX for that purpose, or  
> reuse the current GTX (if there is one). When I referred to in- 
> memory cache, I meant the remote (far) cache. If that (far) cache  
> has a *persistent* cache loader attached to it, then we would need  
> an Xid (XA compliant GlobalTransaction).
>
> Brian Stansberry wrote:
>> I'm not talking about an in-memory cache, but rather a remote  
>> one.  But
>> I think I get what you mean. So, the cache loader gets a storeState()
>> call. Instead of
>> 1) making one or more remove() calls to Cache 2 (the one it's  
>> delegating
>> to).
>> 2) making a bunch of put() calls to Cache 2.
>>
>> it would:
>>
>> 1) Create a bunch of remove Modifications and add them to a list
>> 2) Create a bunch of put Modifications and add them to the list
>> 3) Call CacheLoader.prepare(), passing in a GTX (from where?) and the
>> Modification list
>>
>> Bela Ban wrote:
>>
>>> Why not ? If we're only talking about an in-memory cache (no
>>> persistent cache loader at the far side), then transactions
>>> are passed to the cache in prepare() and commit()/rollback().
>>> Distributed transaction managers wouldn't help here IMO.
>>>
>>> Brian Stansberry wrote:
>>>
>>>> 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.
>>>>
>>
>>
>
> -- 
> Bela Ban
> Lead JGroups / Manager JBoss Clustering Group
> JBoss - a division of Red Hat
>