TransactionLocalDelegateImpl

[dimitris]

A related question to my previous post, since I am there:

TransactionLocalDelegateImpl as an alternative implementation of TransactionLocalDelegate, when a TransactionManager other than TxManager is used, uses the 'this' value rather than the 'unused' TransactionLocal reference, in all calls to the delegate TransactionLocalSynchronization instance (as seen below).

This effectively means the HashMap in TransactionLocalSynchronization always stores a single object, no matter what TransactionLocal->Object association you want to make, within a transaction.

Is this intentional or just forgotten?

(the 'unused' name seems it's intentionall, but I don't understand why :)

Thanks

 public Object getValue(TransactionLocal unused, Transaction tx)
 {
 TransactionLocalSynchronization sync = getSynchronization(tx, false);
 if (sync == null)
 return null;
 return sync.getValue(this);
 }

 public void storeValue(TransactionLocal unused, Transaction tx, Object value)
 {
 TransactionLocalSynchronization sync = getSynchronization(tx, true);
 sync.setValue(this, value);
 }

 public boolean containsValue(TransactionLocal unused, Transaction tx)
 {
 TransactionLocalSynchronization sync = getSynchronization(tx, false);
 if (sync == null)
 return false;
 return sync.containsValue(this);
 }

[adrian.brock]

The difference is in the implementation details:

TransactionLocal

 protected void initDelegate()
 {
 if (transactionManager instanceof TransactionLocalDelegate)
 delegate = (TransactionLocalDelegate) transactionManager;
 else
 delegate = new TransactionLocalDelegateImpl(transactionManager);
 }

It could equally use the passed TransactionLocal rather than the implementation
since there is a one-one correspondance.

There is one object per transaction,
see TransactionLocalSynchronization.valuesByLocal
with the synchronization being transaction scoped.

[dimitris]

"It could equally use the passed TransactionLocal rather than the implementation since there is a one-one correspondance."

But it would be no fun then, right? :)

quite impressive; I'd never guess this one.

[adrian.brock]

"It could equally use the passed TransactionLocal rather than the implementation since there is a one-one correspondance."

But it would be no fun then, right? :)

quite impressive; I'd never guess this one.

It's not intended to be obfuscated. Change it to use the passed TransactionLocal
if it makes the code easier to read/understand.

[dimitris]

That's fine. With this change it could make sense to avoid a few objects by making TransactionLocalDelegateImpl a singleton, since it doesn't hold any state, except for the TM which is not used.

Not important, anway. Thanks.