There's really only two things I need from a transaction model. Personally
I prefer a lambda approach to @Transactional (I use the latter now).
1. Join an existing transaction already in progress (my default case)
2. Force a new transaction even if another transaction is already in
progress on the same thread
3. Rarely I would need a save point. But I can see some scenarios where
I might
I need #2 for those rare cases where I need to do something like INSERT
INTO Users(name, city_id) values ('Kafka',
select_or_insert_city_id('Portland, OR'));
I need #2 to prevent a deadlock when two sessions need to concurrently
create the same city.
For now I just created a wrapper around DSLContext that has
transactionResult like methods annotated with different Transactional
Propagation levels. This is not a feature request, just thought I'd tell
you how I use the different transaction types for background information.
On Friday, January 16, 2015 at 1:06:41 AM UTC-8, Lukas Eder wrote:
>
>
>
> 2015-01-15 19:16 GMT+01:00 Robert DiFalco <[email protected]
> <javascript:>>:
>
>> Hi, things are going mostly amazing with jOOQ. Even though it may be 6
>> years old it is a breath of fresh air in the face of complex Spring and JPA
>> based applications.
>>
>
> Thank you very much for your nice words. The credit also goes to SQL,
> which is even older than jOOQ, but none the less "fresh" :)
>
>
>> So I'm creating my own Transaction abstraction on top of jOOQ that
>> reference counts transactions in the same thread instead of creating save
>> points. So it shares transactions when they nest (by default).
>>
>
> Hmm, I thought we provided that feature out of the box in our
> DefaultTransactionProvider, but we don't. It should've been a flag that
> disables the usage of save points. I'll add an issue for this so we won't
> forget:
> https://github.com/jOOQ/jOOQ/issues/3955
>
>
>> There are other #transactionResult like methods that for example, force a
>> new transaction or a save point, but I doubt I'll ever use these last two,
>> they are just there for completeness.
>>
>> I notice that in your version of #transactionResult that you ALWAYS
>> derive the existing Configuration instance. Before I get rid of this in my
>> abstraction I wanted to know if there was a specific reason for the new
>> object creation? It *seems* like the derived configuration just shares maps
>> and stuff from the old configuration so I'm not sure what the reason for
>> this is.
>>
>
> The reason for this is to create a new org.jooq.Scope for the scope of
> that transaction. While all Configuration.data() flags from the outer scope
> are still available (by copying them to the new scope), whatever you set
> into the inner scope will be cleaned up at the end of the scope, i.e. at
> the end of the transaction. In particular, this includes the possibility of
> locally replacing the ConnectionProvider for the transaction scope.
>
> This is all out-of-the-box behaviour designed for use with JDBC only (not
> with EJB or Spring transactions) that you are free to replace with a more
> appropriate transaction model.
>
--
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.
