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.
