Hey James, That works as long as there is only one thing with side-effects. In the above example I could e.g have the sending of the email logged and so I can no longer use this method. What I'd like to see is whether the top-level construct -wrapping the sending of the email by an agent in a transaction that also updates the database record and potentially logs the fact- is the ideal one here or we can do better.
Thank you. On Thursday, February 21, 2013 3:46:24 AM UTC+1, James Reichley wrote: > > I can't find the reference now, but either in a screencast or a discussion > I read it was mentioned that if you have a single thing that performs > side-effects, you can perform this function last in the transaction without > worrying about any issues. The reasoning here is that if anything before it > fails, the side-effect action was never attempted and if the side-effect > action itself fails then the transaction rolls back like always. > > On Wednesday, February 20, 2013 9:32:14 AM UTC-5, Balint Erdi wrote: >> >> Hey, >> >> So yesterday we discussed concurrency at our meetup ( >> http://www.meetup.com/Budapest-Clojure-User-Group/) and a question >> occurred to me. >> >> Suppose we have a classic web application. (I'm not currently building >> such a web app in Clojure, so that's a "theoretical" question). >> >> When the user signs up, a verification email has to be sent and the >> database entry related to the user has to be updated (or a new datom >> created ;) ) to reflect the fact that we've sent out the email to the user. >> >> First, we want this to be consistent so that the "verification_sent_out" >> db field reflects whether the email has really been sent out or not. >> Secondly, we also want the email to only be sent out once. >> >> My first idea was to use a transaction but if the transaction retries, >> the email could be sent out several times. A fellow Clojurian advised the >> sending of the email to be performed by an agent. The agent is "transaction >> aware" so if the wrapping transaction is retried several times it only >> sends out the email when the transaction successfully runs. >> >> Is this how this actually works? Is there another, simpler and/or more >> robust solution? In the languages I come from (e.g Ruby) I'd use a library >> that handles the queueing and consumption of tasks. Is this how you'd do it >> in Clojure or it's one of these cases where Clojure itself suffices where >> other languages are lacking? >> >> Thank you for your answer, >> -- >> Balint >> >> -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
