Hi Lukas, The difference is crucial. The configuration object is created while creating transaction, in jOOQ one have to pass it around manually. Let's say I am opening tx on message arrival, then router routes to some handler, it routes further somewhere (like DAO or something). Typical case for even tiny app. Passing config object is not an option.
My solution allows one to configure DSLContext at the boot stage of an app (like in EJB or Spring) and then just use it. And this is how I use it in my microservice. Regards, Witold Szczerba On Nov 17, 2014 9:26 AM, "Lukas Eder" <[email protected]> wrote: > Witold, I'm intrigued :) > (and we were missing you at GeeCON Prague!) > > 2014-11-16 13:59 GMT+01:00 Witold Szczerba <[email protected]>: > >> Hi guys, >> The problems with JDBC transactions is that you either have to use raw >> connections to perform operations like commit and rollback, or you >> have to use some heavy heavy stuff like EJB or Spring. >> >> When using jOOQ, there is also third option, introduced by Lukas in >> version 3.4.x, but it is... well, it is useless in anything other than >> a script (sorry for being straight), because one have to pass a >> context/configuration/whatever_you_call_it object everywhere, working >> essentially as a transaction. So in anything other than a simple >> script, we are left alone with "go use Spring or EJB". >> > > Yes, that was the main design goal so far. > > >> As Roger pointed, one could also use Sprint TX module of Spring >> framework. I was almost convinced to do it, since I have just created >> a simple microservice in Java with jOOQ and I need transactions. >> Question: did you see the Spring source code? After 30 minutes of this >> painful experience I decided to never, ever think about using Spring >> anywhere anytime. >> > > Well... :-) > > >> I remember having a discussion with Lukas, trying to stop him >> introducing transactions into jOOQ API. My proposition was to create a >> "jOOT", an ultra lightweight transaction manager which could be used >> anywhere we want tx management with JDBC (plain JDBC, jOOQ, QueryDSL, >> standalone Hibernate, Toplink or other home-grown lib). >> I have even created https://github.com/witoldsz/joot-playground >> >> Months passed and I am here, with jOOQ/JDBC microservice and missing >> transaction management, so I have decided to implement the concept >> described above myself. The problem is I have to figure out the name, >> I cannot use jOOT of course. My first shot is "ULTM" - The Ultra >> Lightweight Transaction Management for JDBC. The beta version, with >> limited capabilities (for start: no nested transactions and some other >> restrictions) is like almost ready. It took me few hours so far. >> >> The very basic concept is like this: "you give me your DataSource and >> I will give back TxManager and another, managed DataSource and you >> will use that DataSource instead of the original one". And all that >> with few dozen lines of code (I hope) with no other, external >> dependencies. > > > So, how is this essentially different from "you give me your Configuration > and I will give back a 'managed' Configuration and you will use that > Configuration instead of the original one" ? > > You essentially implemented the same thing as we did in jOOQ 3.4 - except > that you're doing things on a lower level with JDBC objects, not with jOOQ > objects, making your library more universally usable. > > -- > 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. > -- 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.
