Heh, actually, check this out:
https://github.com/jOOQ/jOOQ/issues/1629<https://github.com/jOOQ/jOOQ/issues/1629?source=cc>
2013/9/24 Lukas Eder <lukas.e...@gmail.com>
>
>
> 2013/9/23 Stéphane Cl <stefatw...@gmail.com>
>
>>
>> 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 jooq-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
