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". 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. 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. Let me know if you are interested in it. I will let you know once the project is usable. Regards, Witold Szczerba On Sat, Nov 15, 2014 at 11:47 PM, Roger Thomas <[email protected]> wrote: > On Friday, November 14, 2014 10:42:08 PM UTC, Garret Wilson wrote: >> >> Thanks so much, Lukas. I'm immediately going to be hitting the books. >> >> I want to mention that we are not using Spring. We are using an embedded >> Jetty instance with a RESTEasy REST interface on one side and a Wicket web >> interface on the other. As you know I'm a bit behind on the latest JavaEE >> database stuff, so if Servlet 3 and Jetty help us out, great. (I will know >> more after reading this weekend.) Otherwise, the only thing "taking care of >> things for us" will be jOOQ and JDBC, so I'm not sure if @Transactional et. >> al. is going to help us out. > > > While Spring looks very much like a complete platform that in your case > would cause issues as you are already using Jetty, you can use parts of > Spring such as their transaction library within your own environment. > > All the examples on the JOOQ site try and simplify the code by not including > all the imports (at times I find this just complicates things). There is an > example on the Spring page at the following link, that does show a more > complete basic example of adding Spring TX to JDBC based code. > > http://spring.io/guides/gs/managing-transactions/ > > The page also gives example build scripts so you can see what is needed > where. > > Roger > > > -- > 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.
