James, I remember something similar to that from this thread: https://groups.google.com/d/msg/datomic/uzmt03egSHI/ThCLFK2iIaMJ
On Thu, Feb 21, 2013 at 3:46 AM, James Reichley <jimmyqpub...@gmail.com>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/<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. > > > -- Please correct me if I'm wrong or incomplete, even if you think I'll subconsciously hate it. -- -- 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.
