[jbosscache-dev] Changes to InvocationContext and TransactionEntry

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(a)jboss.org