I'm trying to understand this line in the run method of LockingTransaction.java.
if(wasEnsured && ref.tvals != null && ref.tvals.point > readPoint)
    throw retryex;

This is in the loop where commutes get rerun during a commit.

The question is how the Ref could have gotten a new committed value
after the current transaction try began given that the current
transaction successfully called ensure on the Ref. Maybe the answer is
that the order of events was as follows:

1) Transaction A starts.
2) Transaction B starts.
3) Transaction B changes Ref R.
4) Transaction B commits its change to Ref R.
5) Transaction A calls ensure on Ref R which succeeds because no
currently running transaction has modified Ref R.
6) Transaction A calls commute on Ref R.
7) Transaction A tries to commit.
8) Transaction A will retry because wasEnsured is true and the latest
committed value for Ref R is after Transaction A started.

This seems like the correct thing to do, but I wonder why Transaction
A was allowed to ensure Ref R. It could determine within the doEnsure
method that Transaction B already committed a change and trigger a
retry of Transaction A at that point. Wouldn't that be better?

Suppose Transaction A calls ensure on Ref R, but doesn't modify Ref R.
It only reads it. In that case, should Transaction A retry due to the
change made by Transaction B?

I think this comes down to the precise meaning of ensure. I understand
it guarantees that no other transaction can modify a given Ref, but
when? Is it since the transaction try began or is it since the call to
ensure? It seems to me it is the former. If this is the case then it
seems better to check for a modification within doEnsure rather than
waiting until the commit begins.

-- 
R. Mark Volkmann
Object Computing, Inc.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to