On Tue, Feb 24, 2009 at 7:34 AM, Laurent PETIT <laurent.pe...@gmail.com> wrote: > 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 ...
Those are interesting reasons to want to know when the events in question occur, but honestly I'm asking just because I want to understand it. I don't have a particular use case in mind. I would be okay with answers like the following if they are true. "A transaction doesn't necessarily recognize that a conflict has occurred at the time it tries to set a new in-transaction value for a Ref. It's more complicated than that and if you want to understand it, you're going to have to study the code." and "A retry doesn't necessarily happen immediately when a conflict is detected. It's more complicated than that ..." I'll go study the code if there aren't simple answers to my questions about when those things occur. > 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 -~----------~----~----~----~------~----~------~--~---
