Hi Colin. You are talking about suricatta documentation? Is build with asciidoctor.
And, about core.async and transactions, suricatta comes with an async abstraction that internally uses a clojure agent for serialize all access to one connection from different threads (managed by core.async internal thread pool). Nothing special is used from jooq for handle it. A suricatta context encapsulates the standard jdbc connection and additional state. As far as I know, JDBC connection is not fully thread safe ( http://stackoverflow.com/questions/1531073/is-java-sql-connection-thread-safe), and the general opinion is avoid use the same connection instance from different threads concurrently. But the suricata approach is share a connection instance between threads but ensuring that only one thread can use it at same time (as I said previously) using serialization semantics of clojure agents. I hope it has been helpful. Cheers Andrey 2015-02-23 22:26 GMT+01:00 Colin Yates <colin.ya...@gmail.com>: > Thanks Christian, that looks interesting. > > By the way, any idea what tool was used to generate the documentation? > > On 23 February 2015 at 21:22, Christian Weilbach > <whitesp...@polyc0l0r.net> wrote: > > -----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. > > -- > 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. > -- Andrey Antukh - Андрей Антух - <andrei.anto...@kaleidos.net> / <n...@niwi.be > http://www.niwi.be <http://www.niwi.be/page/about/> https://github.com/niwibe -- 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.
