2015-02-24 10:15 GMT+01:00 Colin Yates <colin.ya...@gmail.com>: > Hi Andrey - thanks for responding. Asciidoctor looks great! > > I think I understand the sucriata approach which serialises access to > the connection (via the agent). But this doesn't ensure that all > operations using the connection are done in the same thread does it (I > didn't think agents were thread-locked)?. In not then it looks like a > no go. >
Yes, the agent does not ensures that all operations using a connection are done in the same thread. Using agent only ensures that all actions are done in serialized way and only one thread uses the connection at time. > > To be clear, my understanding (which is from a while ago admittedly) > is that JDBC transaction implementations tend to use thread locals to > store a bunch of stuff so it isn't so much the concurrent access which > is a problem (nicely solved by the agent approach) it is ensuring it > is ensuring the same thread is used. > I'm not expert in jdbc, but I have see the source of postgresql jdbc, and the transaction state is bind to the connection, nothing related to thread locals. Thread locals are often used for "transaction mangers" like spring tx, maybe hibernate (I'm not sure because I have never used it), and other lightweight implementations like that https://github.com/witoldsz/ultm ... But in case of plain jdbc transactions, as far as I know, no thread local state is involved. Cheers. Andrey > > On 23 February 2015 at 23:41, Andrey Antukh <n...@niwi.be> wrote: > > 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 > > 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. > > -- > 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.
