Currently each request gets serviced in its own thread (web container) and I am thinking of integrating core.async and I wonder how core.async and a JDBC transactional "unit of work" get on.
Conceptually, this model (thread-per-request) is trivial however the problems are well known. Replacing this with core.async right at the front is trivial but I can see the benefit of sprinkling asynchronous behaviour throughout the (still very trivial) pipeline. Or rather I can see the beauty of decomposed components communicating via channels. My question is about transactionality. I am used to JDBC transactions being thread local and I understand core.async utilises a thread-pool, so how does one implement a "unit of work" that spans multiple channels? I want to do something like: - request comes in - the appropriate handler/service consumes it (either through request mapping, defmethod whatever) - TX starts - in parallel some logging happens (and DB is updated) - the message is handled (and DB is updated) - performance metrics are stored (and DB is updated) - all work on all channels gets finished - TX commits The point is that channels are used only to communicate between disconnected components but they should all participate in the same TX. Is anyone else using channels like this? 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 --- 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/d/optout.
