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 ...
-- 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. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
