We can discuss this for ages, Witold, and we're both right in a way... :) *You* are an excellent engineer, you know exactly what model best suits your particular use-case, and you can implement ULTM easily yourself, and that's perfect.
Whereas *we* get all sorts of support requests for things like Spring, JavaEE and the likes - like the original request in this post. We want to offer an easy, out-of-the-box solution that ultimately works in all use cases. We don't want to be supporting Spring TX five years from now. Those people who know how Spring TX works or who have been using Spring TX all over their applications can continue to use it with jOOQ. Those people who don't know how Spring TX works, will be able to do everything with jOOQ. This will obviously extend to connection pools, eventually. You're absolutely right. ULTM is as easy as using jOOQ transactions. So, to get back at Garret's original questions: - ULTM right now will probably be better suited for Garret's use case than jOOQ transactions - Even better right now for Garret's use case is to use Spring TX (in my opinion) Not sure if Garret's still reading this, though ;-) 2014-11-17 14:26 GMT+01:00 Witold Szczerba <[email protected]>: > All you said above about all the complicated stuff that comes with > transaction management proves that maybe it should not be done in the > jOOQ core. As you said, no solution suits everyone. My solution works > with ThreadLocals and I hadn't have to change a single line of code in > jOOQ. jOOT, as a separate project could handle all the issues the way > ULTM does, but there is no need for jOOT anymore, at least not for > me... > > And using ULTM in scripts is as easy as using jOOQ transactions, maybe > extra single line of code is required. > > But that is just the echo of our conversations from long long time ago :) > > BTW: I was actually forced to create ULTM, because as I said, I had > microservice with no transaction support. > > Regards, > Witold Szczerba > > On Mon, Nov 17, 2014 at 2:11 PM, Lukas Eder <[email protected]> wrote: > > > > > > 2014-11-17 13:47 GMT+01:00 Witold Szczerba <[email protected]>: > >> > >> Hi, > >> I am not sure I am following. > >> You mentioned Spring transactions are working in two modes: implicit > >> by annotations and explicit using tx manager API. That is true. It is > >> the same in EJB, where you can use UserTransaction or declarative > >> transactions. But none of them are forcing users to pass some kind of > >> context object around. > > > > > > Of course not. In a typical EJB context, the objects are registered > globally > > in a JNDI tree. Which is where you can put the jOOQ Configuration. We > just > > haven't implemented this mode yet. And once we implement it, we'll also > > overload the transaction() methods to accept a no-argument-lambda, like > the > > one you have. The Configuration argument to the lambda is a mere tool, in > > case you do want access to that context. > > > > Again, implementing ThreadLocal semantics will drastically impact *all* > of > > jOOQ's API, not just the parts about transactions. This is why I > personally > > prefer postponing that step. > > > >> > >> This is not an option anywhere but scripts. > >> Imagine adding jooq.Configuration (or something like it) to every > >> method signature, including business interfaces? > > > > > > Why? Implement the TransactionProvider SPI and register the Configuration > > globally in a ThreadLocal in your implementation: > > http://www.jooq.org/javadoc/latest/org/jooq/TransactionProvider.html > > > > You will never have to worry about that Configuration anymore. It will > > always be the right one, depending on the local context. > > > >> > >> It is not like the current jOOQ transaction management is equivalent > >> of Spring or EJB "manual" mode. The ULTM or jOOT are and since JDBC is > >> a blocking API by design, all of them are working essentially as you > >> described, using ThreadLocal. > > > > > > Yes. > > > > *but*: We don't enforce the ThreadLocal semantics. It's an option of how > our > > SPIs can be implemented by users, or by future alternative > implementations > > that we ship. I see this as a big plus, as the jOOQ API and its contracts > > are completely async-ready, if only JDBC weren't blocking. > > > > AOP and ThreadLocal magic are heavy influencers on your application > > architecture. We don't enforce these things by offering SPIs that can be > > implemented with whatever semantics you seem fit. We just don't default > to > > the status quo in JavaEE and Spring, without preventing it in the > > implementations. > > > >> > >> BTW: the way jOOQ transactions works now, with nesting support, are > >> much more advanced than what I have done in ULTM. I wish I haven't had > >> to create ULTM in the first place :) > > > > > > No one forced you to do that ;-) > > > > -- > > 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.
