Each and every framework implements the transaction management as part of it's own API - this is insane. I really like the way it is solved in EJB environment, where all you have to do is to get DataSource from container, like: @Inject DataSource dataSource;
As long as you use such a DataSource objects (in one object or in dozen others) - you are safe with transactions. Now, it is very easy to create a DSLContext which creates instance on top of such a DataSource and now you can inject DSLContext everywhere and not having to worry about transactions, because it is handled elsewhere. Once you are done with all your stuff and transaction scope ends, it either commits or rollbacks. Nice thing is that transaction covers much bigger context than single method or even single operation in a callback. One can go from one object to another, then yet to another, each one does not care where it is in the process, I mean no one opens or commits. It makes development much more flexible, because you can reuse your DAO's in many places. If SomeDao#updateStatus() were supposed to open and close transaction, how would we use this in context of bigger operation, where someone else opens and closes transaction? There is one problem with the above. It is not available in simple containers like Jetty, Tomcat. DataSource objects are available there, but they are not transactional. My advise would be to create a sub-project to help database users (yes - database users, not only JOOQ users) to create transactional DataSource objects with simple API, not tied to JOOQ directly (because JOOQ already plays well with transactional datasources!). Once we have this, we can use it with JOOQ the same way we can use JOOQ in EJB. Transactions could be handled like in JTA's UserTransaction, but everything could be extremely lightweight, without all that XA transactions support. What do you think? I find it very nice NOT to follow the path of all other databse frameworks, where each one creates and couples/clutters transactions with it's core API (like *Batis, Hibernate, JPA, etc.). It is just enough to "enhance" the DataSource (like EJB or Spring), give such a DataSource to JOOQ and provide few methods for opening, closing, rolling back. Those operations would act on the DataSource we used to create DSLContext, not the DSLContext itself. Awesome, isn't it? The lightweight transactions done right, yeah :) Regards, Witold Szczerba On 25 September 2013 08:30, Lukas Eder <[email protected]> wrote: > I don't have a recommendation right now, as I haven't given this any deeper > thoughts... > > > 2013/9/25 Stéphane Cl <[email protected]> >> >> Then, what kind of non intrusive transaction manager would you recommend? >> >> >> Le mardi 24 septembre 2013 22:50:44 UTC+2, Lukas Eder a écrit : >>> >>> Heh, actually, check this out: >>> https://github.com/jOOQ/jOOQ/issues/1629 >>> >>> >>> 2013/9/24 Lukas Eder <[email protected]> >>>> >>>> >>>> >>>> 2013/9/23 Stéphane Cl <[email protected]> >>>> >>>>> >>>>> Le dimanche 22 septembre 2013 09:03:19 UTC+2, Lukas Eder a écrit : >>>>>>> >>>>>>> >>>>>>> I haven't yet migrated to 3, my project is successfully using 2.6 in >>>>>>> production. As the only thing I miss in 2.x is also not present in 3.x >>>>>>> (it >>>>>>> has to do with mybatis-like transaction management) I did not upgrade. >>>>>>> Will consider migrating during the next week.. >>>>>> >>>>>> >>>>>> I had studied MyBatis' transaction (session) management before. To me, >>>>>> it seemed to be tailored to only one JDBC transaction models, not JEE/JTA >>>>>> models, or alternative, third party models. What are the good parts of >>>>>> MyBatis' implementation, according to you? >>>>>> >>>>> >>>>> Exactly what you said, it makes jdbc transaction handling easier for >>>>> people who don't use big frameworks. >>>>> Right now, when using a jooq factory I need to call setAutoCommit, >>>>> reset it to true in a finally clause, manually catch high level classes >>>>> such >>>>> as "Exception or Throwable" and rollback. >>>>> >>>>> In the case of mybatis, I do something like that (from memory) >>>>> >>>>> sessionManager.startManagedSession(); //obtains a connection from the >>>>> datasource and set autommit to false, store it in a threadlocal >>>>> >>>>> try { >>>>> sessionManager.select(...); >>>>> sessionManager.update(..); >>>>> sessionManager.delete(...); >>>>> new MyDao( sessionManager).doStuffWithSessionManager(); >>>>> sessionManager.commitTransaction(); >>>>> } >>>>> finally { >>>>> sessionManager.closeTransaction(); //rollback any uncommited change >>>>> if needed, resets autcommit and returns the connection to the datasource. >>>>> } >>>>> >>>>> sessionManager.select() //do a query and immediately release the >>>>> Connection >>>>> >>>>> In jooq, you need to do the following : >>>>> >>>>> 1) set autocommit >>>>> 2) catch and rewrap any Exception, yes *including unchecked ones*, in >>>>> order to be able to call rollback >>>>> 3) reset autocommit in a finally clause >>>>> >>>>> In jooq 2.x, I would have expected such functionality from a DataSource >>>>> based Factory, a system fetching one Connection per request and, in case >>>>> user starts a transaction, store the Connection in a threadlocal and reuse >>>>> it until it's closed. >>>>> I don't remember exactly how a DataSource based Factory currently >>>>> works, but it was clearly not that useful for people not using external >>>>> transaction managers. >>>> >>>> >>>> Yes, that hasn't changed in jOOQ 3.0. Although, integrating with >>>> external transaction managers has become much more easy. >>>> >>>>> But let's forget about the DataSource based Factory and think of a >>>>> simple Factory that just holds a Jdbc Connection, don't you think a few >>>>> transaction helper methods could be useful? >>>> >>>> >>>> I don't generally object that helper methods could be useful. But they >>>> would have a couple of requirements: >>>> >>>> 1. They shouldn't interfere with the more common SPIs used for >>>> integrating with external transaction managers. I.e. the ConnectionProvider >>>> and ExecuteListener contracts must be maintained. >>>> 2. They should clearly communicate the fact that they're JDBC-based in >>>> order for them not to be confused with more sophisticated models. >>>> >>>> I'll certainly think about this again. I could see a MyBatis-like, >>>> simple transaction API in org.jooq.impl.DefaultConnectionProvider, which >>>> already has a couple of JDBC wrapping methods, taking care of the checked >>>> exceptions. >>>> >>>> On the other hand, I've been thinking about supporting >>>> DSLContext.run(new Runnable() { ... }) where the context's underlying >>>> Configuration is put in a threadlocal. This would be mainly useful to add >>>> some more threadsafety already in jOOQ 3.x, before major refactorings for >>>> 4.0 are made. Such a run() method could also initiate a transaction >>>> context... >>>> >>>> But again, once these things get more powerful, they get more complex >>>> and possibly contradict other contracts, which are more important... >>>> >>>> Let's keep thinking about these things... >>>> >>>> Lukas >>> >>> >> -- >> 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/groups/opt_out. > > > -- > 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/groups/opt_out. -- 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/groups/opt_out.
