Re: Antw: Re: OSGi Transaction control fails with hibernate

[alexander.sahler]

Tim,

please find the project here:
https://github.com/sahlex/declarative-poc

Best, Alexander.


>>> 
Note that this work should be done as part of a new transaction control
service implementation (there’s some common code which should help to
speed up implementing it), not as changes to the current implementation,
which is undergoing stabilisation as the Reference Implementation of the
OSGi Transaction control service.

Also this update still won’t avoid the need for the JPA resource
provider to have a custom plugin for transaction integration. The whole
point of a managed resource is that it integrates with the Transaction
Control service that gets passed to it, not by integrating with a third
party service which may, or may not, be involved.

Alexander - is there any chance of seeing the proof of concept code? It
seems as though it’s pretty close to working with the existing bundles.

Regards,

Tim




On 14 Sep 2017, at 12:42, 
 wrote:

I'll give it a try. Maybe with a little guidance of you guys. First of
all I'll try to inject a JTA TransactionManager into tx-control instead
of the internal one. If that is working, I'll let you know.


>>> 



On 14 Sep 2017, at 10:46, Guillaume Nodet  wrote:



2017-09-14 11:40 GMT+02:00 Timothy Ward :


Hi Alexander,

As has been discussed on the Aries lists before, I have no problem with
someone creating a separate implementation of the Transaction Control
service which leverages the OSGi JTA Service Specification. The reason
that the current implementation doesn’t do this is twofold:

By embedding a transaction manager the current Tx Control
implementation can avoid the javax.transaction split package from the
JVM. This makes the implementation easier to use and deploy because the
user doesn’t need to mess around with the boot class path, or worry
about what JTA version is available
By embedding a transaction manager the current Tx control
implementation can rely on specific behaviours of the transaction
manager that it uses. This means that the Tx control implementation can
support the last resource gambit and XA recovery.
Fwiw, as I already indicated, the pax-transx project provides a layer
solving those problems, in addition of providing additional features and
pluggability.

Would you be interested to incorporate it in Tx Control ?

This is not something that I have the time to do, but another
implementation of a transaction control service with a pluggable
transaction manager would be a great addition.




Guillaume
 



If this is a proof of concept project then are you able to share it
somewhere (e.g. GitHub)? I’d like to help you get to the bottom of the
NPE that you’re seeing as I don’t think it should be possible for that
to be happening!

Finally - yes the Aries user list is the best place to talk about this,
but I don’t want to move the conversation myself as I don’t know whether
you’re registered for that list, and don’t want you to miss my replies.

Regards,

Tim




On 14 Sep 2017, at 07:53, 
 wrote:

Hi Tim.

I'm using the 2.6.1 version of aries jpa support already. Normal
transaction control with blueprint and @Transactional annotation was
working fine.

To have better control over startup dependencies and cope with
disappearing and appearing services during runtime we invest some time
in a Proof-Of-Concept for switching over to declarative services (DS).
Everything works fine so far - even restful services for DS with
cxf-dosgi works fine. Last bit to get it working is transaction
management. With DS, the @Transactional annotation is not working
anymore due to the lack of interceptors with DS.

What do you think of the idea that tx-control should pick up a JTS
Transaction manager from the service registry instead of creating an own
on
e with new operator which is in fact tightly coupled. To implement
loose coupling here we should add a factory that may be configurable in
the factory config file.

BTW, should we switch the discussion to aries group still?

Best, Alexander.



Hi Alexander,

That looks like it should be fine - what version of Aries JPA are you
using? There were some fixes made to Aries JPA in 2.4.0 to add support
for JPA 2.1 configuration properties which are needed by the transaction
control implementation, and I think that there were then more fixes in
2.5.0 which are needed to get XA working with Hibernate. 2.6.1 is the
latest release version.

Regards,

Tim




On 13 Sep 2017, at 15:42, alexander.sah...@brodos.de wrote:

Thanks Tim for the update.

I tried the approach with providing a factory config in
karaf.dir/etc/org.apache.aries.tx.control.jpa.xa.cfg with config as:
osgi.unit.name=DSContext2
osgi.jdbc.driver.class=org.h2.Driver
url=jdbc:h2:mem:article
user=sa
password=

whilst having a mininmal persistence.xml like:






(without the dialect I see another exception; Access to
DialectResolutionInfo cannot be null when 'hibernate.dialect' not set).

Now I get further in the 

Re: Antw: Re: OSGi Transaction control fails with hibernate

[Timothy Ward]

Seems to be working ok now with extremely minor changes.

https://github.com/sahlex/declarative-poc/pull/1 


Best Regards

Tim

> On 15 Sep 2017, at 08:36, alexander.sah...@brodos.de wrote:
> 
> Tim,
> 
> please find the project here:
> https://github.com/sahlex/declarative-poc 
> 
> 
> Best, Alexander.
> 
> 
> 
> Note that this work should be done as part of a new transaction control 
> service implementation (there’s some common code which should help to speed 
> up implementing it), not as changes to the current implementation, which is 
> undergoing stabilisation as the Reference Implementation of the OSGi 
> Transaction control service.
> 
> Also this update still won’t avoid the need for the JPA resource provider to 
> have a custom plugin for transaction integration. The whole point of a 
> managed resource is that it integrates with the Transaction Control service 
> that gets passed to it, not by integrating with a third party service which 
> may, or may not, be involved.
> 
> Alexander - is there any chance of seeing the proof of concept code? It seems 
> as though it’s pretty close to working with the existing bundles.
> 
> Regards,
> 
> Tim
> 
> 
>> On 14 Sep 2017, at 12:42, > > > > wrote:
>> 
>> I'll give it a try. Maybe with a little guidance of you guys. First of all 
>> I'll try to inject a JTA TransactionManager into tx-control instead of the 
>> internal one. If that is working, I'll let you know.
>> 
>> 
>> 
>> 
>>> On 14 Sep 2017, at 10:46, Guillaume Nodet >> > wrote:
>>> 
>>> 
>>> 
>>> 2017-09-14 11:40 GMT+02:00 Timothy Ward >> >:
>>> Hi Alexander,
>>> 
>>> As has been discussed on the Aries lists before, I have no problem with 
>>> someone creating a separate implementation of the Transaction Control 
>>> service which leverages the OSGi JTA Service Specification. The reason that 
>>> the current implementation doesn’t do this is twofold:
>>> 
>>> By embedding a transaction manager the current Tx Control implementation 
>>> can avoid the javax.transaction split package from the JVM. This makes the 
>>> implementation easier to use and deploy because the user doesn’t need to 
>>> mess around with the boot class path, or worry about what JTA version is 
>>> available
>>> By embedding a transaction manager the current Tx control implementation 
>>> can rely on specific behaviours of the transaction manager that it uses. 
>>> This means that the Tx control implementation can support the last resource 
>>> gambit and XA recovery.
>>> Fwiw, as I already indicated, the pax-transx project provides a layer 
>>> solving those problems, in addition of providing additional features and 
>>> pluggability.
>>> 
>>> Would you be interested to incorporate it in Tx Control ?
>> 
>> This is not something that I have the time to do, but another implementation 
>> of a transaction control service with a pluggable transaction manager would 
>> be a great addition.
>> 
>>> 
>>> Guillaume
>>>  
>>> 
>>> If this is a proof of concept project then are you able to share it 
>>> somewhere (e.g. GitHub)? I’d like to help you get to the bottom of the NPE 
>>> that you’re seeing as I don’t think it should be possible for that to be 
>>> happening!
>>> 
>>> Finally - yes the Aries user list is the best place to talk about this, but 
>>> I don’t want to move the conversation myself as I don’t know whether you’re 
>>> registered for that list, and don’t want you to miss my replies.
>>> 
>>> Regards,
>>> 
>>> Tim
>>> 
>>> 
 On 14 Sep 2017, at 07:53, >>> > >>> > wrote:
 
 Hi Tim.
 
 I'm using the 2.6.1 version of aries jpa support already. Normal 
 transaction control with blueprint and @Transactional annotation was 
 working fine.
 
 To have better control over startup dependencies and cope with 
 disappearing and appearing services during runtime we invest some time in 
 a Proof-Of-Concept for switching over to declarative services (DS). 
 Everything works fine so far - even restful services for DS with cxf-dosgi 
 works fine. Last bit to get it working is transaction management. With DS, 
 the @Transactional annotation is not working anymore due to the lack of 
 interceptors with DS.
 
 What do you think of the idea that tx-control should pick up a JTS 
 Transaction manager from the service registry instead of creating an own 
 one with new operator which is in fact tightly coupled. To implement loose 
 coupling here we should add a factory that may be configurable in the 
 factory config file.
 
 BTW, should we switch the discussion to aries group still?
 
 Best, Alexander.
 
 
 
 Hi Alexander,
 
 That looks