On Dec 8, 7:44 pm, Dave Griffith <
dave.l.griff...@gmail.com> wrote:
> 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.
>
I've added io! blocks, which will throw an exception when run in a
transaction:
(dosync (io! 42))
-> java.lang.IllegalStateException: I/O in transaction (NO_SOURCE_FILE:
0)
They take an optional string which will serve as the exception text:
(dosync (io! "bad" 42))
-> java.lang.IllegalStateException: bad (NO_SOURCE_FILE:0)
await and await-for now contain io! blocks.
Rich
>
> On Dec 8, 6:07 pm, Stuart Halloway <
stuart.hallo...@gmail.com> 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 softwaretransactions. It was clear to everyone why I/O
> > > needed to be prohibitted intransactions, but questions were raised as