Thanks everyone for taking time on this. I've got it now.
My two take-aways:
* There was never any inconsistent result (and there never would be)
* worrying about transaction re-start is wrong - transactions might
re-start and the transactional code MUST always be correct under restart.
Neale
Hi Neale,
I think refs #1 is fine as it stands. That said, perhaps this clarification
will help: Start means as of current try, not as of first try. If the
transaction has no way to see new things on retry, then the retry cannot
possibly succeed where the initial try failed.
Stu
Hi,
Hi,
[disclojure]: I've asked about this on SO, but figured out what was
happening myself[1] and that led to this enquiry.
It seems that the consistency of refs within an STM transaction (dosync)
depends on whether the ref has history.
So if you create 2 refs and then read them in a transaction
Hi,
[disclojure]: I've asked about this on SO, but figured out what was happening
myself[1] and that led to this enquiry.
It seems that the consistency of refs within an STM transaction (dosync)
depends on whether the ref has history.
So if you create 2 refs and then read them in
So if you create 2 refs and then read them in a transaction they could be
inconsistent with each other. i.e they won't necessarily return the value
the ref had at the start of the transaction.
However, if you give the refs some history by updating them in a prior
transaction, then the two
Hi
Transaction read point is changed every time when transaction is
started or retried.So the result is all right.If you want the ref1 cloud
not be modified by other transactions ,you can use ensure:
(defn deref-delay-deref [ref1 ref2 delay]
(.start
(Thread.
Hi Stu,
The point is that there's no reason for the READ transaction to restart, it
has only made reads of refs and those reads should be consistent with each
other from the snapshot of the the ref world as per...
In practice, this means:
1. All reads of Refs will see a consistent snapshot
