Thanks a lot for this detailed analysis and the pointers to the Java implementation, Stefan! That's excellent and very helpful.
I still wonder, why the first transaction blocks write access. My overall understanding of the transaction system is that changes to referenced values remain in-transaction before committing them, a write-lock shouldn't be needed. I'm surprised, that the second transaction is the one who has to retry 71 times even though the first transaction hasn't committed anything yet. Cheers, Dominikus P.S.: Thanks for the idea to use 'future' to spawn a thread! On Aug 29, 5:42 pm, Stefan Kamphausen <ska2...@googlemail.com> wrote: > The call to alter already wrote to the Ref, this requires a write-lock on > the ref (see LockingTransaction.java/doSet). After that it sleeps a while > and gets to its commit phase. The other transactions retries in the > meantime. Consider the following code, which introduces some atoms for > counting the retries > > (defn tz [] > (let [rr (ref 10) > a1 (atom 0) > a2 (atom 0)] > (println "Starting future") > (future > (dosync > (swap! a1 inc) > (alter rr + 100) > (Thread/sleep 8000))) > (println "Sleeping a bit") > (Thread/sleep 1000) > (println "Another dosync") > (time > (dosync > (swap! a2 inc) > (ref-set rr 1))) > [@rr @a1 @a2 (.getHistoryCount rr)])) > > user> (tz) > Starting future > Sleeping a bit > Another dosync > "Elapsed time: 7001.554 msecs" > [1 1 71 0] > > Note, how the 71 retries nice fit the approximately 7 seconds left and the > 100 miliseconds time-out (LOCK_WAIT_MSECS) for the lock used in > LockingTransaction.java/tryWriteLock. > > Transactions with significantly different run-times should be avoided, > although there is some point at which older transactions will get their > turn. This could be another explanation of the effect. Take a look at the > barge-function in LockingTransaction.java > > Hope this helps, > Stefan -- 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
