Hi Witold, I was expecting you :-) 2013/9/25 Witold Szczerba <[email protected]>
> 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. > You can use Spring in such environments. 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 :) > I mostly agree with this, specifically the fact that there should be some help for users to set up their transactions. Contributions to the manual are very welcome! On the other hand, I still don't exclude the usefulness of a slim transaction API that operates directly on a JDBC Connection. I know that in larger applications, this tends to be a worse solution than what you described. But if jOOQ is used for smaller applications, why not provide something out of the box, which doesn't interfere with "better" solutions? -- 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.
