zcaudate
zcaudate

Reputation: 14258

what are some good programming principles for using nested dosync blocks?

I really like STMs, but am hoping to get some advice about how to use transactions properly, especially when one block of transactions depends on another

for example I have some code:

(defn unschedule-task [tt task-id]
  (dosync
   (doseq [entry .....]
    (tk/kill-all! (:task entry)))
   (v/delete! tt [[:task :id] task-id])))

(defn schedule-task [tt task schedule & [enabled? optt]]
  (dosync
   (unschedule-task tt (:id task))
   (v/insert! tt {.....})))

Basically, unschedule-task has a dosync block, and schedule-task calls unschedule-task in its own dosync block as it needs both the deletion and the insertion to go through in one transaction.

How far can one push this and what are the pitfalls to avoid? (I'm thinking there may be issues with circular dependencies but can't think of an example off the top of my head....)

Upvotes: 3

Views: 144

Answers (1)

Joost Diepenmaat
Joost Diepenmaat

Reputation: 17771

transactions are flattened; starting a new transaction during a transaction doesn't do anything. IOW, either all ref modification succeed during the outer transaction or the whole outer transaction is restarted. This means there should be no dependency issues.

Upvotes: 1

Related Questions