Question

I have this code:

(defn on-thread [f]
  (.start (Thread. f)))

(def myref (ref 0))

(on-thread
  #(loop [x 100]
     (when (> x 0)
       (do
         (Thread/sleep 100)
         (println "myref is:" @myref)
         (recur (dec x))))))

(on-thread 
  #(dosync
    (println "transaction1 initial:" @myref) 
    (alter myref inc)
    (println "transaction1 final:" @myref) 
    (Thread/sleep 5000)
    (println "transaction1 done")))

(on-thread 
  #(dosync
     (println "transaction2 initial:" @myref) 
     (Thread/sleep 1000)
     (alter myref inc)
     (println "transaction2 final:" @myref) 
     (println "transaction2 done")))

When I run this, it’s plain that the first transaction runs first, and it alters the ref’s value to 1 – but the other threads are don’t see this: okay, of course, because the first transaction hasn’t finished yet. So I think at this moment there were no “commit” yet back to the ref.

But at this time, the first transaction goes to sleep and while it’s sleeping, the second transaction tries to alter the ref’s value. And it’s get rolled back, and retried by the environment!
Why?
How the second transaction “see”, that something happened (or will be happening) with the ref by the first transaction?

I think it would be more logical if the second transaction would be able to alter the in-transaction value of the ref (from 0 to 1) and then sleep 1000, and then finally make a successful commit, then the first transaction would be retried.
But this is not the case.

Why?

Answer 1

The second transaction is retried because when it goes to alter your ref, it sees that it has already been altered by another non-committed transaction. Therefore it is retried until the first transaction commits.

If by some chance the second transaction altered the ref first, then yes, the first transaction would be retried. However, that just isn’t the case because your second transaction occurs way later (in CPU time) after the first.