Mahalo
v3.0.0 Release Notes

"Mahalo" is the name of the contributed River transaction manager implementation from Sun Microsystems. The River Transaction Specification is available in HTML.

Changes since the v2.2.0 release

Changes since the v2.1.1 release

Changes since the v2.2.0 release

None

Changes since the v2.1 release

None

Changes since the v2.0.1 release

Configuration

The following configuration entries have been added to the Mahalo implementation:

• settlerPool - The pool of threads used to settle outstanding transactions.
• taskPool - The pool of threads used to settle transactions.

These "thread pool" objects can now be sized for end user applications. See Mahalo's package documentation for more detail.

Bug Fixes of Interest

The following bugs have been addressed in this release:

4285733: Is the Transaction spec correct about permissible votes?

Section TX.2.7 of the Jini (TM) Transaction Specification was changed to correct the permissible vote outcomes for prepare. Specifically, the COMMITTED vote was changed to PREPARED.

4394196: Txn specs fixes

Section TX.1.3 of the Jini (TM) Transaction Specification was changed to emphasize that Java(TM) Remote Method Invocation (Java RMI) semantics are replied upon and not any particular implementation. Section TX.2.3 removed a confusing "crash count" example. In section TX.2.7, the paragraphs dealing with abort and prepareAndCommit were modified for clarity. Section 2.8 was modified to note that the commit point record can be removed after successfully returning from abort (in addition to commit). Section 2.8.1 added an additional bullet item noting that getState can return ABORTED.

4761012: prepareAndCommit semantics amibiguous wrt idempotentcy

Section TX.2.6 & TX.2.7 of the Jini (TM) Transaction Specification were changed to note that prepareAndCommit calls may not be idempotent.

5054742: Transaction spec does not specify whether or not participant commit is atomic

Section TX.3.5 of the Jini (TM) Transaction Specification was changed to note that participants are not required to implement atomic abort and commit calls.