Hello, I suspect you want to guess *when* things happen because you're tempted (or you're doing) do call code with side effect inside the transaction. So you say to yourself : "if the transaction is aborted at this place then this code will not have been called and this thing will not have been printed out or something like that" ..., and then you are concerned with gathering more information that those currently garanteed (and who are sufficient from the perspective of "pure functions without side effects", as far as correctness is concerned).
Now maybe you are concerned with performance consideration, when you would be bothered by a long calculation having to be made several times if the transaction is retried ? Indeed, then knowing if there are ways to make the transaction "fail quickly" (before performing the long calculation) could make sense ... ? 2009/2/24 Mark Volkmann <r.mark.volkm...@gmail.com> > > On Mon, Feb 23, 2009 at 6:23 PM, Rich Hickey <richhic...@gmail.com> wrote: > > > > On Feb 23, 2009, at 4:47 PM, Mark Volkmann wrote: > > > >> 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. > >> > >> -- > > > > The answer is here: > > > > http://clojure.org/refs > > > > "should a transaction have a conflict while running, it is > > automatically retried" > > Thanks for trying to explain this. I apologize for taking so long to > understand it. Perhaps the guarantees are purposely vague to avoid > guaranteeing too much. > > My question is focused on timing. Above it says "should a transaction > have a conflict" and "it is automatically retried". I'm trying to > understand *when* it realizes there is a conflict and *when* it > retries. I suspect it realizes the conflict when it tries to set a new > in-transaction value. I suspect it retries immediately rather than > waiting from some other event to occur. I'm just trying to verify my > guesses. > > > and > > > > "3. No changes will have been made by any other transactions to any > > Refs that have been ref-set/altered/ensured by this transaction." > > -- > 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 -~----------~----~----~----~------~----~------~--~---
