[jbosscache-dev] Changes to InvocationContext and TransactionEntry

[Manik Surtani]

Both of these classes were, among other things, collecting information  
on locks acquired for their respective scopes.  Nothing wrong with  
this, except that it was a bit haphazard in the manner in which it was  
done.  There was no consistent naming (getInvocationLocksAcquired() in  
the invocation context and getLocks() in the TransactionEntry),  
consistent return value guarantees (IC could return null, while TE  
always returned a defensively copied list) or storage consistency (IC  
used an ArrayList, TE used a LinkedHashSet).  And finally, it was a  
PITA in the code - I saw a lot of repeated code like:

if (ctx.getTransactionEntry() == null)
{
	// get locks from ctx
}
else
{
	// get locks from TE
}

So here is what I have done to clean things up.

1.  Consistent method names.  getLocks(), addLock(), addAllLocks(),  
removeLock(), clearLocks().
2.  Properly documented expected return types.  E.g., getLocks()  
returns a defensively copied, immutable list.
3.  Documented automatic scope upgrading.  E.g., *always* use the  
methods on InvocationContext.  If a transaction is in scope, the IC  
will delegate the call to the TE.  Much simpler for calling code.
4.  Consistent storage.  LinkedHashSets, see JBCACHE-874 if you care  
why.
5.  Weakly typed methods.  locks are Objects, Lists returned are  
untyped.  Had to do this to support MVCC which uses Fqns as locks and  
not NodeLocks.  We can make things strongly typed again once we drop  
OL/PL support.

Further to the above, I propose we rename TransactionEntry to  
TransactionContext, to be consistent with InvocationContext.  WDYT?

Cheers
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org