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