On Mon, Feb 23, 2009 at 3:19 PM, Rich Hickey <richhic...@gmail.com> wrote
>
> On Feb 23, 2009, at 3:44 PM, Mark Volkmann wrote:
>
>> On Mon, Feb 23, 2009 at 2:31 PM, Dan <redalas...@gmail.com> wrote:
>>>> If I understand correctly, when there is an attempt to modify a Ref
>>>> that has been modified in another thread since the current
>>>> transaction
>>>> began then the current transaction will retry immediately. Isn't it
>>>> true that it has no chance of completing until the transaction that
>>>> changed that Ref either commits or rolls back? If that is true,
>>>> wouldn't it make sense to make the retry wait until that other
>>>> transaction is finished? Maybe the point of retrying immediately is
>>>> that it can at least get through some of its work (the part before
>>>> it
>>>> tries to change the Ref in question) before it has to check on that
>>>> other transaction again.
>>>
>>> Until there is a commit, no one but the transaction knows that
>>> those refs
>>> are meant to hold new values.
>>
>> Ah ... I didn't know that. I did know that the new value wasn't
>> visible outside the uncommitted transaction, but I thought other
>> transactions were aware that some other transaction was changing it.
>> Thanks for explaining that!
>>
>>> When your transaction notices something is
>>> wrong and retries, the other transaction will *always* be finished.
>>> Which of
>>> course doesn't mean another transaction might not prevent it to
>>> finish
>>> again.
>>
>
> This stuff is not right.
>
> You really shouldn't be concerned about the details of what happens
> when *inside* a transaction. The guarantees of http://clojure.org/refs
> are met, but the exact flow can get complex - there is blocking,
> deadlock avoidance and conflict resolution, aging and barging etc.
>
> I frequently see these "this happens then that happens" imaginings
> about what happens inside transactions. Nothing other than what is
> documented is guaranteed, and those guarantees are about what a
> transaction sees, and what its effects are on commit, not the order of
> operations inside a transaction.
>
> If you're not doing side effects in transactions, you shouldn't care,
> and you shouldn't be doing side effects in transactions.
Without getting into the implementation details, is there anything
wrong with this statement?
While in a transaction, if an attempt is made to modify a Ref
that has been modified in another transaction that has committed
since the current transaction started,
the current transaction discards all its in-transaction Ref changes
and retries by returning to the beginning of the dosync body.
--
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
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
-~----------~----~----~----~------~----~------~--~---
