transactions in Kilns

gistfile1.lisp

;;      This simple snapshotting trigger example keeps a kell running but
;;      sends a copy of its current state over `?rc`.
(trigger* {snapshot (list {?kell} {?rc})}
  (trigger [kell ?a]
    [kell ?a]
    {rc {kell ?a}}))

;;      This is a simple example of a rollback trigger. (Actually, it’s
;;      more general than a rollback – there is no restriction on the new
;;      state.) It simply grabs a kell and replaces its state in situ.
(trigger* {replace {?kell-name ?new-state}}
  (trigger [kell-name ?current-state]
    [kell-name new-state]))

;;      This is a rough transactional system that expands upon the two
;;      patterns above. It takes the name of an existing kell and a
;;      process to attempt. The existing kell is sandboxed and the process
;;      is composed with the kell's current state. If the process
;;      generates a `{commit}`, the kell is un-sandboxed with its new
;;      state. If the process generates a `{rollback},` the kell is un-
;;      sandboxed with its original state.
(trigger* {transaction {kell {?kell}} {process ?process}}
  (trigger [kell ?original-state]
    (new output
      {sandbox (list (par [kell orginal-state process]
                          (trigger (down {rollback})
                            {output original-state})
                          (trigger (par (down {commit}) [kell ?new-state])
                            {output new-state}))
                     {output})}
      (trigger {output ?final-state} [kell final-state]))))

;;;      I'm not sure how useful the transactions are. If you want to make
;;;      sure multiple values are changed atomically, the following should
;;;      be sufficient:

(trigger (par {value1 ?x} {value2 ?y})
  (par {+ (list ?x 1 {value1})}
       {- (list ?y 1 {value2})}))

;;;      I suppose `transaction` might be useful in more complicated
;;;      situations, where there are multiple conditions to check if the
;;;      system is in the proper state for the transation, or if the
;;;      transaction is more dependent on “can I do this now?” rather than
;;;     “do this whenever the system reaches the appropriate state.”