-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23.02.2015 18:20, Colin Yates wrote: > 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? I have done it in IndexedDB in JavaScript and had to use the proper callback API (1), because otherwise transactions break. I guess you cannot do channel operations inside a JDBC operation since they are executed in the threadpool (by the state-machine) while each JDBC connection seems to be pinned to a thread, so you cannot participate in the same transaction from another thread of the threadpool. But if you can wrap your blocking JDBC stuff in a singular thread call, you might be able to use async/thread (probably less than you want).
There is also https://github.com/niwibe/suricatta, but I have no experience with it. jooq seems to solve the the thread per request problem decoupling into async operations you have in mind. Cheers, Christian (1) https://github.com/ghubber/konserve/blob/master/src/cljs/konserve/indexeddb.cljs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU65n6AAoJEKel+aujRZMkwaAH/1Eq2/vr84WqNq6u2rcG4ly+ xkByy602oMy9/ScK1/ytv/kFdPG+qAYmtQ4EHq/LGUma3zLjpPdrf49A1RUGfVii fbwIUiRgUJWdigrGiSf/2zIn972MgIfc4qKFj/+/2hJNZIAwlAKiPQSvG2VPrHo7 dskeQZeCZI4yGSz4+dQFGmKvjiAum+UConkzn0T/N2XGknerFsLonXyvpbTv/SCC NwNoRJzI39kjIyhfUuwbwHoy0/DtbxjvkbrLHeyGIKGOJ75QutWY6gvkRsSlzS5g A2jVtZo/hw02di3mxrD1vwSZ2PWads2juKjCmmOQrIPofSBWyVmoGeQ/qyD/Dgw= =Wi7E -----END PGP SIGNATURE----- -- 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.
