Friday, 20 March 2009

JBoss Cache 3.1.0.BETA1

3.1.0's been somewhat delayed due to problems with Non-blocking State Transfer, but these have finally been overcome.

Here's a quick summary first. The first Beta of JBoss Cache 3.1.0 Cascabel is now available in the usual places (download, docs, forums). The main feature of Cascabel is Non-blocking State Transfer, a new and highly efficient state transfer mechanism. Also, since MVCC was introduced in JBoss Cache 3.0.0 Naga, lock striping was used for the write locks held by nodes. While lock striping is efficient, it always exposes a slight risk of deadlock. In Cascabel, we now offer a lock-per-Fqn option for MVCC, which is more expensive than striped locks but is guaranteed to be deadlock-free. In addition, there are a host of bug fixes across the board, so this is definitely a version you should upgrade to if you use JBoss Cache 3.0.x.

Now for the details, starting with Non-blocking State Transfer (NBST). NBST has certain pre-requisites, specifically, that you use MVCC for locking and that you use JGroups' STREAMING_STATE_TRANSFER protocol. NBST works by allowing state to be read, free of locks thanks to MVCC, streamed to the receiver, all the while allowing the sender to continue changing state. What is key is that the sender also maintains a transaction log for this period. Once the state is delivered to the recipient and applied, the transaction log is then also streamed across, until the transaction log reaches a predetermined, small size - or it is detected that the transaction log grows faster than it can be streamed. In either of these cases, a lock is acquired on all processing, causing the sender to block all new transactions for a short period while the last of the transaction log is streamed and applied. After this, both the sender and receiver release locks and start processing requests, the new joiner now at the same state as the sender.

The main benefit of this approach is that the sender is not blocked for the majority of the time while generating and streaming state (made all the more apparent when there is a lot of state to send) and the cluster proceeds to operate. Naturally, the implementation is a fair deal more complicated than what is described quite simplistically above, with a fair few more details and edge cases to be dealt with. :-)

NBST is disabled by default, but can be enabled by using a simple configuration switch (Configuration.setUseNonBlockingStateTransfer() or <stateretrieval nonblocking="true" />).

So do give it a whirl, feedback, as always, is appreciated.



Mark Little said...

What do you mean by "transaction log"? One from JBossTS or your own (and in which case what's the definition of a transaction)?

Manik Surtani said...

Our own transaction log. It would be more accurate to say "modification list", I suppose, since the log includes transactional as well as non-transactional writes.

A TransactionLog instance is responsible for logging all modifications, whether pertaining to a committed 1 or 2 phase transaction, non-transactional writes, as well as prepares pending commit.

Mark Little said...

OK, so it's not a Transaction Log it's more a log of participant updates that should be committed or rolled back eventually by the transaction system (which has it's own log of who's in the transaction). True?

Manik Surtani said...

Precisely. Like I said, "modification list" is probably more appropriate.