On Tue, Feb 24, 2009 at 9:11 AM, Laurent PETIT <laurent.pe...@gmail.com> wrote: > Mark, I think Rich made a point very clear : even if you study the *current* > code and understand it, there is no guarantee that the code will still > behave as you've understood it in two month, because you will have looked at > internal implementation detail. So this kind of knownledge can be dangerous > if you start to "count on it" in your own code, I think ...
Ah ... that makes sense. Thanks Laurent! > 2009/2/24 Mark Volkmann <r.mark.volkm...@gmail.com> >> >> 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. >> >> > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
