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
{t
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 all,
(my first post, let's hope it shows up soon)
On Tuesday, April 17, 2012 7:35:52 AM UTC+1, sw1nn wrote:
>
> Hi,
>
> We're all agreed that the behaviour I'm seeing is because the READ
> transaction is re-starting. It sounds like the community thinks that's the
> right behaviour and I'm ha
I think the key point is that the read transaction doesn't change the
value,so it will see the snapshots before or after ref1 updated,and both of
two snapshot could be treated consistently.
All reads of Refs will see a consistent snapshot of the 'Ref world' as of
the starting point of the transact
Hi,
We're all agreed that the behaviour I'm seeing is because the READ
transaction is re-starting. It sounds like the community thinks that's the
right behaviour and I'm happy to be educated
I don't believe that the READ transaction should need to restart just
because the underlying refs chan
Hi,
I know your meaning.But it is real that the read transaction is
restarted,you can observer it by stm-profile:
https://github.com/killme2008/stm-profiler
(.start (Thread.
#(do (Thread/sleep 1)
(prn (ref-stats r1)
(Thread/sleep 2000)
r1 statistics:
{:de
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 of
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.
> 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 t
> 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
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
11 matches
Mail list logo
