On Oct 15, 2:51 pm, hobnob <hob...@ml1.net> wrote: > Hi, > > I'm just starting to get my head wrapped around STM just by reading > about it so I can make a decision on whether to port a Java project to > Clojure. > > a) can STM transactions contain calculations that take a 'long' time, > let's say computing the cryptographic hash of a plaintext. I'd > 'ensure' the input parameters such as plain text, hash algo and bit- > length, compute the hash (can be slow) and store the hash in a ref. > What I'd need here is that the calculation is interrupted if the > transaction is aborted for a retry. No need to complete the long > calculation if we aren't going to store the result anyway. The > existing convention in Java is to set the interrupt flag on a thread > which is queried ever now and then by long-running calculations. This > is a convention that many Java libraries adhere to. So how to do this > interrupting?
Also a tough question. If you have a non transactional flag, it doesn't need to provide the value you expect it to have. And using a transactional flag could also lead to strange problems like transactions always conflict on change of that flag. > > b) With long-running calculations, nested dosyncs should really result > in nested transactions. The point being if a transaction has several > long-running calculations. E.g. first compute a hash, then encrypt the > hash with a public key. In that case, if the 'ensured' parameters that > the second encrypt part depends on are changed concurrently but not > the parameters/result of the first part, then only the second > calculation has to be repeated, not both. The second part could be > enclosed in an inner dosync but currently Clojure will unnecessarily > redo the whole thing. I guess you need a propagation level: RequiresNew. And at the end you need to be able to commit all the transactions as one. Afaik Clojure has no support for it, but I don't think it is very hard to add if clojure also exposes some kind of prepare methods to makes sure that the transaction is able to commit. For the Multiverse STM I have introduced CommitBarriers for this purpose, but I don't think they would be hard to add to the Clojure STM. > > c) Somewhat different: I'm not supposed to do I/O in a transaction > because the transaction might be repeated and that will repeat the I/ > O. But maybe that's what I want. The I/O could be a network output > sending the computed value over the net to be stored on a remote > machine instead of being stored in a local ref. I *do* want the > computed value of each retry to be sent over the net. I guess my setup > here could be considered an ad-hoc distributed TM, this touches the > other discussion of "STM with external transactions" in this group. All communication with non transactional datasources from within a transaction is hard. You can do some stuff with the deferred and compensating actions if the transaction commits or aborts..But I haven't found a solution for this problem either. This was one of the main reasons for MS to drop their STM research project. > > Thanks -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
