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. Having said so, I believe that it is a great idea to publish your transaction framework! I suggest you put a couple of well-documented examples in a README.md file of your GitHub repository. You don't necessarily need a Google Group, I think. For starters, communication via GitHub issues might be sufficient. If you're interested in publishing a guest post on the jOOQ blog, let me know. We're syndicated with DZone, JCG, JAXenter.com, Tech.Pro, and we're also talking to voxxed.com (a new collaboration between Devoxx and Parleys). This might help you kick-start your transaction API. Cheers, Lukas 2014-11-17 9:48 GMT+01:00 Witold Szczerba <[email protected]>: > 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. > -- 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.
