Am 04.08.2010 um 23:16 schrieb Andrew Coppin: > Frank Kupke wrote: >> Andrew, >> >> Thanks for pointing your finger at it >> Am 04.08.2010 um 17:48 schrieb Andrew Coppin: >> >>> In that case, is there a way to determine whether or not the rest of the >>> transaction completed? Because it looks like you can the same exception >>> either way, regardless of whether a commit happened or not. >>> >> Ah, now I see. Excellent point. I was always focussing the commit case which >> is well designed, I am certain. >> > > OK, so there's design work to do here. (Or at least, things to think about.) > But that's OK. It's new and exciting. :-) >
Andrew, oops. Your question was sure pointing me to an issue I had to rethink twice. My last reply to you was shot a bit too quickly. The implemented design throws an exception to the application in two cases: - if the app reads a TVar, calling readTVar, and the TVar is not accessible - if a transaction, a call of atomic, is validated and one or more of the to be validated TVars are not accessible (that I said also before) However, *no* exception is thrown if the transaction *has been* validated and the failure occurs afterwards during the commit phase (here my reply was incorrect). In this case the transaction silently commits all remaining (i.e. non failing) TVars. Failing TVars are simply ignored besides internal cleanup work which is transparent to the app. Back to your original question then: A transaction throwing the distribution exception (other exceptions are possible, too, but are orthogonal to this one) signals to the app that the transaction did not commit because of a TVar failure (Btw, reading a TVar also occurs in a transaction and in case of such an exception the app knows also that the transaction did not finish, it did not even try to validate, though). What about a transaction that committed in spite of unavailable TVars? Answer: The app would not know until the next time it tries to access the failing TVar. Then it definitely gets an exception, either because of reading it or validating the transaction. A committed (i.e. returning) transaction tells the app that whatever it wanted to synchronize with other parts of the system succeeded and it can continue its work. It does not guarantee, though, that the other parts are still alive. This failure semantics, of course, can be discussed. Any input is welcome. Frank PS: I have uploaded DSTM 0.1.2 with minor changes based on the discussion here. _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
