TxInterceptor and 1-phase commits

[manik]

As a part of the refactoring process for JBossCache 1.3, I've genericised the OptimisticTxInterceptor (which created tx's as needed and handled synchronizations for tx completion) so that it is the starting point of *all* interceptor chains and handles all transactional aspects of the cache.

This has greatly simplified the ReplicationInterceptor, the new InvalidationInterceptor, Unlock- and PessimisticLockInterceptors.

As a part of this, I've noticed the following:

* Optimistic chain always uses 2-phase commits.
* Pessimistic chain uses 1-phase commits when replication mode is asynchronous.

Is the latter necessary? Could we move to a 2PC mechanism for the pess. locking/async. replication scenario?

The way this is handled in the case of opt. locking/async. replication is that the prepare phase is always synchronous, it is just the commit phase that we run asynchronously.

I feel that by using 2PC throughout, we'd greatly simplify the interceptors even further. The drawback, of course, is that the prepare phase will always be synchronous. What are peoples' thoughts around this? Does this altogether beat the purpose of async replication?

[belaban]

#2 No, we still need async transactional replication.


#1 Why is the OptTxInterceptor starting point for all of this ? If so, the we should rename it to TxInterceptor (but don't we have such a class already) ?

[manik]

already been renamed - there was no such thing as a tx interceptor before that

[manik]

I agree we need async transactional repl, but is using 1PC the right way to do this? Should we follow the way we deal with this in O/L and have the prepare phase as synchronous but the commit phase as async.? Better data integrity?

[brian.stansberry]

This would have the effect of forcing HttpSession replication to run synchronously, as the cache changes we make to reflect changes to the session are always wrapped in a tx. Doing this would significantly reduce the responsiveness of webapps.

[ben.wang]

Yes, key is we do replication during "prepare" phase (we still do this right?). So if "prepare" is synchronous, it behaves almost like a REPL_SYNC mode, which is not what we want.

[manik]

Yes, replication is done during a prepare. My only disconcert with running prepare asynchronously is that it does risk data integrity. It does certainly affect scalability though.

Anyway, one way or the other I'd like to be consistent - opt. locking async replication to follow pess. locking async replication (i.e., 1PC) or vice versa?

[belaban]

The risk of losing data is documented, as with all other asynchronous replication schemes, so no problem there IMO. Let devs choose for themselves...
I don't see a diff between O/L and P/L here, as locking and replication are orthogonal issues IMO

[manik]

I don't see a diff between O/L and P/L here, as locking and replication are orthogonal issues IMO

I agree. And that is why it bugged me that async replication was handled differently in these 2 cases. Anyway, now that the tx interceptor is separate, I can make this change to replication handling in the optimistic case, so that async replication uses a 1-phase commit and prepares are asynchronous, as in the pessimistic case.