FYI, please note that the "current" above means the current HEAD code, which works somewhat differently from the currently released code (1.4.0.SP1).

In 1.4.0.SP1:

If the state provider has a failure marshalling transient, associated or persistent state, it returns null for the entire state transfer. The recipient interprets the null as a failure.

On the recipient side, if there is a problem integrating the transient state, associated state is *not* integrated. Don't remember why I did it that way; probably because associated is useless without the transient state. However, if there's a problem integrating either transient or associated state, integration of persistent state is still allowed to proceed. That behavior of allowing persistent to proceed after a failure with transient goes back a long way.

"bstansberry@jboss.com" wrote:
That behavior of allowing persistent to proceed after a failure with transient goes back a long way.

My gut instinct is for an atomic approach as well.

The only use case where continuing after partial failure is conceptually valid is when the persistent state contains a complete representation of the state; transient state is just there to provide a hot cache.

1) There has to be a persistent state transfer or a shared cache loader.
2) No passivation.

Then, if you're going to fall back and rely on persistent state, you have to be sure you can remove any in-memory state that may have been integrated before the failure. If associated state fails, you have to clear transient as well.

Do we lock the root node for the *persistent* state transfer, like in the case of the in-memory state ?
Would it maybe be better to lock on the CacheLoader in question rather than on the root node ? Possible inconsistencies ?
Usually, the persistent state is *much bigger* than the in-memory state, so locking the entire tree for the persistent state transfer might take a long time...

Good point.

In the cache loader/store interceptors, I no longer sync on the cache loader but on an object attributed to the fqn in question (improves concurrency in the loader/store interceptors) (see BaseCacheLoaderInterceptor)

But this means that locking on the cache loader during ST will not prevent the interceptors from writing to the loader. What you'd need to do is to get a loader lock on a per-fqn basis using the lock map in the BaseCacheLoaderInterceptor. This lock map will probably have to be refactored out of this Interceptor for this though, perhaps into the CacheLoaderManager.

My feeling on this is still about a -0; i.e. I think its better to just do it atomically but I don't feel strongly about it. Doing it non-atomically requires careful coding that's going to be easy for later maintainers to break.

Also, the use case I described where continuing after failure is valid is based on the fact that the persistent data is "gold" while the in-memory data is just a speed optimization. That means that if the persistent transfer fails, the transferred in-memory data needs to be removed.

I vote a +1 on atomicity. I wouldn't continue after failure, even if we have a complete persistent state and an incomplete transient one. Just easier to deal with.