The basic use case is as a guard for I/O, to prevent them from from filling the disk/spamming the network accidentally in case of transaction live-lock. Probably a bit more paranoia than is idiomatic in the dynamically-typed world, but there are domains where that's necessary. The workaround is perfectly fine, although it looks like exposing a method in LockingTransaction would be more performant.
--Dave Griffith On Dec 8, 6:07 pm, Stuart Halloway <[EMAIL PROTECTED]> wrote: > Hi Dave, > > It looks like LockingTransaction.getRunning would need to be made > public. What do you plan to do with it? > > As a workaround: > > (defn in-tx? [] (try (ensure (ref true)) (catch > IllegalStateException e false))) > > Stuart > > > > > I gave a small talk on Clojure this afternoon to my team. It went > > well, and got the expected oohs and ahhs with respect to the potential > > of software transactional memory. One question asked, though, was > > about I/O in software transactions. It was clear to everyone why I/O > > needed to be prohibitted in transactions, but questions were raised as > > to whether there was any way to actually prevent it. Looking through > > the API, I couldn't find any way of detecting when execution was > > occuring in a transactional context or not. > > > --Dave Griffith --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
