You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Thomas Hug <th...@gmail.com> on 2014/02/12 11:20:15 UTC
[Discuss] Data Module - Transactional Repositories
Not sure where we stopped in the discussion but AFAIR we had two approaches
here:
1) An automatic internal tx handling if one is needed by the query,
probably similar to what the JPA module does in the
EnvironmentAwareTransactionStrategy. Could eventually be controlled by an
attribute on @Repository defaulting to active.
2) Integration with @Transactional of the JPA module. For this we'd also
have to look at:
- Aligning EntityManager resolution between the two modules. That could
include moving the EntityManagerResolver into the JPA module API and
eventually removing the current qualifier-based resolution. That one would
need some more thoughts to get out something consistent.
- Eventually exposing the resolved EM @TransactionScoped so the repository
can easily access it.
- Deal with PartialBeans not picking up interceptors - AFAIR this was
reported to be an issue on some Weld versions?
+1 on 2) - makes for me much more sense from a user perspective.
Re: [Discuss] Data Module - Transactional Repositories
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Thomas,
would be great to get it in 0.6, any idea if it would be possible? I
should be able to help once decided and if needed.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-12 12:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> While it works with JTA it is ok for me, I think it should be
> compatible with our @Transactional and EE 7 one. I think reusing
> @Transactional is important in declaration (on method) so maybe the
> way to go.
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2014-02-12 11:40 GMT+01:00 Jean-Louis MONTEIRO <je...@gmail.com>:
>> +1 for 2/ as well.
>> That is right from an end user experience point of view.
>> Also right to reuse and put in common some parts of JPA and Data module
>> Closer to Java EE 7 @Transactional approach
>>
>> JLouis
>>
>>
>>
>> 2014-02-12 11:20 GMT+01:00 Thomas Hug <th...@gmail.com>:
>>
>>> Not sure where we stopped in the discussion but AFAIR we had two approaches
>>> here:
>>>
>>> 1) An automatic internal tx handling if one is needed by the query,
>>> probably similar to what the JPA module does in the
>>> EnvironmentAwareTransactionStrategy. Could eventually be controlled by an
>>> attribute on @Repository defaulting to active.
>>>
>>> 2) Integration with @Transactional of the JPA module. For this we'd also
>>> have to look at:
>>> - Aligning EntityManager resolution between the two modules. That could
>>> include moving the EntityManagerResolver into the JPA module API and
>>> eventually removing the current qualifier-based resolution. That one would
>>> need some more thoughts to get out something consistent.
>>> - Eventually exposing the resolved EM @TransactionScoped so the repository
>>> can easily access it.
>>> - Deal with PartialBeans not picking up interceptors - AFAIR this was
>>> reported to be an issue on some Weld versions?
>>>
>>> +1 on 2) - makes for me much more sense from a user perspective.
>>>
>>
>>
>>
>> --
>> Jean-Louis
Re: [Discuss] Data Module - Transactional Repositories
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hello,
1) a producer + qualifier would be easier on entitymanager side so I'd
propagate it to the repository.
2) em in transactionscoped should be useless since if you produce the
em you are already in a scope so already cached by CDI itself, no?
3) we don't really need interceptors since we can invoke it ourself in
the handler (for me CRUD + transaction need to fit together so not
shocking to keep them linked. JPA is linked to JTA BTW ;)), it would
even be important to be able to avoid nested transactions by default
(I don't recall what does default @Tx impl). Where I'm less confident
is with current @Tx impl we can't force a new transaction so we
doesn't cover all needed case. But should be enough to start.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-17 7:51 GMT+01:00 Thomas Hug <th...@gmail.com>:
> Yes would be great to get this sorted out soon. Looks like 2) is the
> preferred way to go, which would also mean some work on the JPA module.
>
> - Any thoughts on how the Data EntityManagerResolver fits in the picture
> there?
> - Also [1] seems rather nasty in this context. Is there a better way
> dealing with it than just trying to detect it has not been picked up and
> then call the TransactionStrategy by ourself?
>
> [1] https://issues.apache.org/jira/browse/DELTASPIKE-419
>
>
> On Sun, Feb 16, 2014 at 10:10 PM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
>> Hi Thomas,
>>
>> would be great to get it in 0.6, any idea if it would be possible? I
>> should be able to help once decided and if needed.
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2014-02-12 12:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>> > While it works with JTA it is ok for me, I think it should be
>> > compatible with our @Transactional and EE 7 one. I think reusing
>> > @Transactional is important in declaration (on method) so maybe the
>> > way to go.
>> > Romain Manni-Bucau
>> > Twitter: @rmannibucau
>> > Blog: http://rmannibucau.wordpress.com/
>> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> > Github: https://github.com/rmannibucau
>> >
>> >
>> >
>> > 2014-02-12 11:40 GMT+01:00 Jean-Louis MONTEIRO <je...@gmail.com>:
>> >> +1 for 2/ as well.
>> >> That is right from an end user experience point of view.
>> >> Also right to reuse and put in common some parts of JPA and Data module
>> >> Closer to Java EE 7 @Transactional approach
>> >>
>> >> JLouis
>> >>
>> >>
>> >>
>> >> 2014-02-12 11:20 GMT+01:00 Thomas Hug <th...@gmail.com>:
>> >>
>> >>> Not sure where we stopped in the discussion but AFAIR we had two
>> approaches
>> >>> here:
>> >>>
>> >>> 1) An automatic internal tx handling if one is needed by the query,
>> >>> probably similar to what the JPA module does in the
>> >>> EnvironmentAwareTransactionStrategy. Could eventually be controlled by
>> an
>> >>> attribute on @Repository defaulting to active.
>> >>>
>> >>> 2) Integration with @Transactional of the JPA module. For this we'd
>> also
>> >>> have to look at:
>> >>> - Aligning EntityManager resolution between the two modules. That could
>> >>> include moving the EntityManagerResolver into the JPA module API and
>> >>> eventually removing the current qualifier-based resolution. That one
>> would
>> >>> need some more thoughts to get out something consistent.
>> >>> - Eventually exposing the resolved EM @TransactionScoped so the
>> repository
>> >>> can easily access it.
>> >>> - Deal with PartialBeans not picking up interceptors - AFAIR this was
>> >>> reported to be an issue on some Weld versions?
>> >>>
>> >>> +1 on 2) - makes for me much more sense from a user perspective.
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Jean-Louis
>>
Re: [Discuss] Data Module - Transactional Repositories
Posted by Thomas Hug <th...@gmail.com>.
Ok with 3) you basically mean we don't rely on @Transactional, but rather
on the TransactionStrategy?
Sounds fine too. Would require some tricks to bridge from InvocationHandler
to InvocationContext, and then again having the TXStrategy pick up the
repository EM (haven't checked yet what that means in detail).
On Mon, Feb 17, 2014 at 8:49 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> Hello,
>
> 1) a producer + qualifier would be easier on entitymanager side so I'd
> propagate it to the repository.
> 2) em in transactionscoped should be useless since if you produce the
> em you are already in a scope so already cached by CDI itself, no?
> 3) we don't really need interceptors since we can invoke it ourself in
> the handler (for me CRUD + transaction need to fit together so not
> shocking to keep them linked. JPA is linked to JTA BTW ;)), it would
> even be important to be able to avoid nested transactions by default
> (I don't recall what does default @Tx impl). Where I'm less confident
> is with current @Tx impl we can't force a new transaction so we
> doesn't cover all needed case. But should be enough to start.
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2014-02-17 7:51 GMT+01:00 Thomas Hug <th...@gmail.com>:
> > Yes would be great to get this sorted out soon. Looks like 2) is the
> > preferred way to go, which would also mean some work on the JPA module.
> >
> > - Any thoughts on how the Data EntityManagerResolver fits in the picture
> > there?
> > - Also [1] seems rather nasty in this context. Is there a better way
> > dealing with it than just trying to detect it has not been picked up and
> > then call the TransactionStrategy by ourself?
> >
> > [1] https://issues.apache.org/jira/browse/DELTASPIKE-419
> >
> >
> > On Sun, Feb 16, 2014 at 10:10 PM, Romain Manni-Bucau
> > <rm...@gmail.com>wrote:
> >
> >> Hi Thomas,
> >>
> >> would be great to get it in 0.6, any idea if it would be possible? I
> >> should be able to help once decided and if needed.
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >> 2014-02-12 12:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> >> > While it works with JTA it is ok for me, I think it should be
> >> > compatible with our @Transactional and EE 7 one. I think reusing
> >> > @Transactional is important in declaration (on method) so maybe the
> >> > way to go.
> >> > Romain Manni-Bucau
> >> > Twitter: @rmannibucau
> >> > Blog: http://rmannibucau.wordpress.com/
> >> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> > Github: https://github.com/rmannibucau
> >> >
> >> >
> >> >
> >> > 2014-02-12 11:40 GMT+01:00 Jean-Louis MONTEIRO <je...@gmail.com>:
> >> >> +1 for 2/ as well.
> >> >> That is right from an end user experience point of view.
> >> >> Also right to reuse and put in common some parts of JPA and Data
> module
> >> >> Closer to Java EE 7 @Transactional approach
> >> >>
> >> >> JLouis
> >> >>
> >> >>
> >> >>
> >> >> 2014-02-12 11:20 GMT+01:00 Thomas Hug <th...@gmail.com>:
> >> >>
> >> >>> Not sure where we stopped in the discussion but AFAIR we had two
> >> approaches
> >> >>> here:
> >> >>>
> >> >>> 1) An automatic internal tx handling if one is needed by the query,
> >> >>> probably similar to what the JPA module does in the
> >> >>> EnvironmentAwareTransactionStrategy. Could eventually be controlled
> by
> >> an
> >> >>> attribute on @Repository defaulting to active.
> >> >>>
> >> >>> 2) Integration with @Transactional of the JPA module. For this we'd
> >> also
> >> >>> have to look at:
> >> >>> - Aligning EntityManager resolution between the two modules. That
> could
> >> >>> include moving the EntityManagerResolver into the JPA module API and
> >> >>> eventually removing the current qualifier-based resolution. That one
> >> would
> >> >>> need some more thoughts to get out something consistent.
> >> >>> - Eventually exposing the resolved EM @TransactionScoped so the
> >> repository
> >> >>> can easily access it.
> >> >>> - Deal with PartialBeans not picking up interceptors - AFAIR this
> was
> >> >>> reported to be an issue on some Weld versions?
> >> >>>
> >> >>> +1 on 2) - makes for me much more sense from a user perspective.
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Jean-Louis
> >>
>
Re: [Discuss] Data Module - Transactional Repositories
Posted by Thomas Hug <th...@gmail.com>.
Yes would be great to get this sorted out soon. Looks like 2) is the
preferred way to go, which would also mean some work on the JPA module.
- Any thoughts on how the Data EntityManagerResolver fits in the picture
there?
- Also [1] seems rather nasty in this context. Is there a better way
dealing with it than just trying to detect it has not been picked up and
then call the TransactionStrategy by ourself?
[1] https://issues.apache.org/jira/browse/DELTASPIKE-419
On Sun, Feb 16, 2014 at 10:10 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> Hi Thomas,
>
> would be great to get it in 0.6, any idea if it would be possible? I
> should be able to help once decided and if needed.
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2014-02-12 12:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> > While it works with JTA it is ok for me, I think it should be
> > compatible with our @Transactional and EE 7 one. I think reusing
> > @Transactional is important in declaration (on method) so maybe the
> > way to go.
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
> >
> >
> > 2014-02-12 11:40 GMT+01:00 Jean-Louis MONTEIRO <je...@gmail.com>:
> >> +1 for 2/ as well.
> >> That is right from an end user experience point of view.
> >> Also right to reuse and put in common some parts of JPA and Data module
> >> Closer to Java EE 7 @Transactional approach
> >>
> >> JLouis
> >>
> >>
> >>
> >> 2014-02-12 11:20 GMT+01:00 Thomas Hug <th...@gmail.com>:
> >>
> >>> Not sure where we stopped in the discussion but AFAIR we had two
> approaches
> >>> here:
> >>>
> >>> 1) An automatic internal tx handling if one is needed by the query,
> >>> probably similar to what the JPA module does in the
> >>> EnvironmentAwareTransactionStrategy. Could eventually be controlled by
> an
> >>> attribute on @Repository defaulting to active.
> >>>
> >>> 2) Integration with @Transactional of the JPA module. For this we'd
> also
> >>> have to look at:
> >>> - Aligning EntityManager resolution between the two modules. That could
> >>> include moving the EntityManagerResolver into the JPA module API and
> >>> eventually removing the current qualifier-based resolution. That one
> would
> >>> need some more thoughts to get out something consistent.
> >>> - Eventually exposing the resolved EM @TransactionScoped so the
> repository
> >>> can easily access it.
> >>> - Deal with PartialBeans not picking up interceptors - AFAIR this was
> >>> reported to be an issue on some Weld versions?
> >>>
> >>> +1 on 2) - makes for me much more sense from a user perspective.
> >>>
> >>
> >>
> >>
> >> --
> >> Jean-Louis
>
Re: [Discuss] Data Module - Transactional Repositories
Posted by Romain Manni-Bucau <rm...@gmail.com>.
While it works with JTA it is ok for me, I think it should be
compatible with our @Transactional and EE 7 one. I think reusing
@Transactional is important in declaration (on method) so maybe the
way to go.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-12 11:40 GMT+01:00 Jean-Louis MONTEIRO <je...@gmail.com>:
> +1 for 2/ as well.
> That is right from an end user experience point of view.
> Also right to reuse and put in common some parts of JPA and Data module
> Closer to Java EE 7 @Transactional approach
>
> JLouis
>
>
>
> 2014-02-12 11:20 GMT+01:00 Thomas Hug <th...@gmail.com>:
>
>> Not sure where we stopped in the discussion but AFAIR we had two approaches
>> here:
>>
>> 1) An automatic internal tx handling if one is needed by the query,
>> probably similar to what the JPA module does in the
>> EnvironmentAwareTransactionStrategy. Could eventually be controlled by an
>> attribute on @Repository defaulting to active.
>>
>> 2) Integration with @Transactional of the JPA module. For this we'd also
>> have to look at:
>> - Aligning EntityManager resolution between the two modules. That could
>> include moving the EntityManagerResolver into the JPA module API and
>> eventually removing the current qualifier-based resolution. That one would
>> need some more thoughts to get out something consistent.
>> - Eventually exposing the resolved EM @TransactionScoped so the repository
>> can easily access it.
>> - Deal with PartialBeans not picking up interceptors - AFAIR this was
>> reported to be an issue on some Weld versions?
>>
>> +1 on 2) - makes for me much more sense from a user perspective.
>>
>
>
>
> --
> Jean-Louis
Re: [Discuss] Data Module - Transactional Repositories
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
+1 for 2/ as well.
That is right from an end user experience point of view.
Also right to reuse and put in common some parts of JPA and Data module
Closer to Java EE 7 @Transactional approach
JLouis
2014-02-12 11:20 GMT+01:00 Thomas Hug <th...@gmail.com>:
> Not sure where we stopped in the discussion but AFAIR we had two approaches
> here:
>
> 1) An automatic internal tx handling if one is needed by the query,
> probably similar to what the JPA module does in the
> EnvironmentAwareTransactionStrategy. Could eventually be controlled by an
> attribute on @Repository defaulting to active.
>
> 2) Integration with @Transactional of the JPA module. For this we'd also
> have to look at:
> - Aligning EntityManager resolution between the two modules. That could
> include moving the EntityManagerResolver into the JPA module API and
> eventually removing the current qualifier-based resolution. That one would
> need some more thoughts to get out something consistent.
> - Eventually exposing the resolved EM @TransactionScoped so the repository
> can easily access it.
> - Deal with PartialBeans not picking up interceptors - AFAIR this was
> reported to be an issue on some Weld versions?
>
> +1 on 2) - makes for me much more sense from a user perspective.
>
--
Jean-Louis