Yes, Lukas, this is all helping immensely. I'm away from my computer, but ULTM sounds like it's what we could use. I was hoping not to bring in even a fingernail on the monster that is Spring. G
On November 17, 2014 12:22:54 PM GMT-02:00, Lukas Eder <[email protected]> wrote: >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 a topic in the >Google Groups "jOOQ User Group" group. >To unsubscribe from this topic, visit >https://groups.google.com/d/topic/jooq-user/-2laC-pYsbI/unsubscribe. >To unsubscribe from this group and all its topics, 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.
