On Tue, Sep 9, 2008 at 11:58, Jules Bean
Maybe this is an idea for an extension to the STM system, adding something like unsafeIOToSTM, except that in addition to the main IO action, it also takes two more IO actions that are invoked on rollback and commit, respectively.
This might allow for integration with transactional systems (e.g. a remote transaction on an rdbms), although to support two-phased commit we'd need a third action for the "prepare" step.
That would be an absolutely killer feature.
A common problem in large systems is that the underlying RDBMS supports transactionality, but then the software layer has to handle its own rollbacks. I've seen some nasty bugs when the DB rolled back and the software didn't.
If we could have a transactional RDBMS linked into STM with matching semantics, that would be a very nice thing.
I think this is entirely doable. For comparison we already have done this with another STM framework, the DSTM2 library for Java. I.e. we hooked into prepare, commit and rollback and integrated with both MySQL transactions and a transactional file system library from Apache Commons. I'm not yet involved enough with the GHC library code, but I guess this would require the addition of a "prepare" phase to the STM code. There's also the question of what to do when the remote TX system indicates failure, should the transaction be retried or aborted? In the DSTM2 case we make it abort and throws an exception encapsulating the remote error to the code that initiated the TX (in Haskell's case, the caller of atomically). On a related note, we do have a paper on utilizing the STM system for authorization and policy enforcement in general. The paper is to be presented at CCS'08, and has an implementation on top of DSTM2, but we have a technical report in the works that implements this on top of the Haskell STM and gives operational semantics for the whole thing. You can find the conference paper on my website: http://www.hvergi.net/arnar/publications cheers, Arnar