[jbosscache-dev] JBoss Cache 2.0.0.ALPHA status

[Bela Ban]

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