Hi all,
I have done the following changes in org.jboss.tm:
- Transaction hash and ID generation has moved to
XidImpl, and XidImpl now has a hashCode() method.
- TransactionImpl no longer has a reference to the
TransactionManager and now delegates directly to
TxCapsule instead of indirectly through the
TxManager. This kills an extra level of indirection
and saves a hashtable lookup on most calls. As a
consequence the txCapsules hashtable and the
whatever(Transaction tx) methods have been removed
from TxManager.
- To facilitate transaction import TxManager now has
a HashMap activeCapsules that maps transaction IDs
to TxCapsules. Lookup on this map is only done when
a transaction needs to be imported after having
travelled.
- TxCapsule now remembers the set of TransactionImpl
that represent the transaction (there may be more
than one if the transaction has travelled on an
intra-VM "remote" call). When the transaction
terminates the TxCapsule now calls all the frontend
TransactionImpl to inform them. The frontends will
use this call to clear their reference to the
TxCapsule.
- Since we no longer hold any references to the
TxCapsule after the transaction has terminated, we
can safely reuse TxCapsule instances. This eases
the burden on the heap allocator and the garbage
collector. Now TxManager holds a list of inactive
TxCapsule instances. I use SoftReference to hold
the inactive TxCapsule instances so that the
garbage collector can claim them if we run low on
memory.
- The collection classes in TxCapsule have been
replaced by arrays of the appropriate type. Code
has been added to expand these arrays when needed.
Using this approach we save an extra call to the
collection instance, and we do not have to do
a cast (with associated runtime type-checking) on
values fetched from the collection.
This also means that the suspendedResources hash
is gone and has been replaced by a table of resource
states. Instead of the suspendedResources hash
lookup I now traverse the tables manually to see
if a resource is suspended. As there will normally
be a very small number of resources enlisted with a
transaction, this is as fast as a hash table lookup.
As you can see these changes are not bug-fixes or new
functionality, but rather performance enhancements.
If these changes pass my final testing, I hope to
commit later this evening if nobody have objections.
Best Regards,
Ole Husgaard.