Hi everyone! 2014-11-18 16:23 GMT+01:00 Lukas Eder <[email protected]>:
> Hi Andrey, > > 2014-11-17 15:51 GMT+01:00 Andrey Antukh <[email protected]>: > >> Andrey. >> >> Sent from my Nexus 4 >> On Nov 17, 2014 11:37 AM, "Lukas Eder" <[email protected]> wrote: >> > >> > Yes, I understand that part of the difference - and I remember your >> criticism. Essentially, jOOQ currently expects you to pass the transaction >> reference (as contained in a derived Configuration) around, whereas ULTM >> probably keeps it somewhere in a ThreadLocal. In jOOQ, the "ThreadLocal >> solution" might emerge in a future version as well, in parallel to the >> existing explicit version (https://github.com/jOOQ/jOOQ/issues/2732). I >> can't promise any ETA, as this might introduce significant changes to all >> of jOOQ's internals. >> > >> > But having both models in parallel isn't so uncommon. In Spring, for >> instance, you can also choose to use "implicit" transactions via >> @Transactional annotations, or "explicit" ones via a transaction manager >> that you have to keep around. In the end, there are these two models. I >> don't see a clear advantage of one over the other, apart from personal >> taste. But I agree that jOOQ currently doesn't offer the "implicit" model. >> > >> >> Implicit is always better than implicit. Personally I prefer the current >> tx jOOQ api over any other like spring... >> It is very flexible and allow implement own implicit tx management >> without much of problems. >> >> Implicit tx management is not suitable for all cases. In my opinion any >> implicit transaction management should be out of scope of jOOQ (different >> library is a good place for it...) >> > *For the group:* Andrey has implemented Suricatta ( > http://niwibe.github.io/suricatta). A SQL API built on top of jOOQ for > Clojure. > Thanks for the presentation. > > *Andrey:* I haven't had a look at the implementation details of your > TransactionProvider yet. If I'm not mistaken, the sources are these ones > here, right? > > https://github.com/niwibe/suricatta/blob/7af06380bf566edce092091ff3ff2410fd81107e/src/suricatta/core.clj#L109 > Yes, you are right. > > > Or explicitly: > > > (defn atomic-apply "Execute a function in one transaction or > subtransaction." [^Context ctx func & args] (let [^Configuration conf (. > derive (proto/get-configuration ctx)) ^TransactionContext txctx ( > transaction-context conf) ^TransactionProvider provider (. > transactionProvider conf)] (doto conf (.data "suricatta.rollback" false) > (.data "suricatta.transaction" true)) (try (.begin provider txctx) (let [ > result (apply func (types/->context conf) args) rollback? (.data conf " > suricatta.rollback")] (if rollback? (.rollback provider txctx) (.commit > provider txctx)) result) (catch Exception cause (.rollback provider (. > cause txctx cause)) (if (instance? RuntimeException cause) (throw cause) ( > throw (DataAccessException. "Rollback caused" cause))))))) > > What would your TransactionProvider look like in plain Java code, more or > less? > This code is representing something that jOOQ has already implemented (very similar, concretely on https://github.com/jOOQ/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/impl/DefaultDSLContext.java#L299). Obviously it has different semantics, because it also handles explicit rollback flag instead of using exceptions. But this uses a default transaction provider of jOOQ, because it is simple and sufficient for implement over it any sugar syntax. The java code maybe can a little bit verbose, but only for java syntax and types declaration, but it would be mostly the same. The grace of use clojure in this case, is its flexible syntax that makes use of explicit transaction management (without thread locals) very intuitive. Let see an example: (atomic ctx (do-something-with-ctx ctx) (atomic ctx (do-something-other-in-a-subtransaction-with-ctx ctx))) (`atomic` is a clojure macro that behind the schenes uses the `atomic-apply`, see previous code example) Something like this in java7 would be very very verbose, because it implies creating a lot of anonymous clases. With java8 this verbosity is reduced obviously. But with clojure syntax flexibility, it allows use the explicit transaction management, without any threadlocal in very comfortable way. Implement something implicit is also very easy, but is less necessary if a language that are you using allows some facilities for work with that. Personally, I don't understand the advantages of using something like sprint tx. They mostly provides accidental complexity and try to solve something that language can not solve. jOOQ currently provides simple and flexible transaction provider interface, that enables that any one can implement over it the concrete use case of that any one can need. In this way, I think jOOQ is more agnostic of frameworks, that is good. (It obviously make things easy for implement something like suricatta with own transaction semantics on top of the jOOQ transaction provider without much problems). Obviously, is a subjective opinion. ;) Greetings. Andrey > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Andrey Antukh - Андрей Антух - <[email protected]> / <[email protected] > 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 "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
