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