[jbosscache-dev] JBoss Cache 2.0.0.ALPHA status

[Manik Surtani]

Precisely; this should work.  I presume the GTX used is the one in  
the current context (if transactional) or a new one if not.
--
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 11 Sep 2006, at 22:31, 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.