Karaf and Transaction Control Service Specification

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Karaf and Transaction Control Service Specification

Alex Soto
Hi,

Is it possible to use Transaction Control Service Specification with Karaf?



Any good example or tutorial?

(I am currently using Aries JPA Template, but I would like to move on to use the standard)

Best regards,
Alex soto




Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

jbonofre
Hi,

Partly yes, but not fully, as it's OSGi R7 (it would be fully supported
in Karaf 4.3.x).

Anyway, using scr jpaTemplate or JPA jta namespace, you can specify the
transaction on methods.
You can take a look on JPA example in Karaf about that.

Regards
JB

On 05/02/2019 16:34, Alex Soto wrote:

> Hi,
>
> Is it possible to use Transaction Control Service Specification with Karaf?
>
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html
>
>
> Any good example or tutorial?
>
> (I am currently using Aries JPA Template, but I would like to move on to
> use the standard)
>
> Best regards,
> Alex soto
>
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

cschneider
In reply to this post by Alex Soto
I am pretty sure you can use it. 

There is an example in enroute:

If you use the same bundles it should work.
We can create a karaf feature in the aries-tx-control repo for it to make it easier to install.

Christian

Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto <[hidden email]>:
Hi,

Is it possible to use Transaction Control Service Specification with Karaf?



Any good example or tutorial?

(I am currently using Aries JPA Template, but I would like to move on to use the standard)

Best regards,
Alex soto






--
--
Christian Schneider

http://www.liquid-reality.de

Computer Scientist

Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

jbonofre
I'm volunteer to add the features repository in aries-tx-control. That
would be helpful in Karaf.

Regards
JB

On 05/02/2019 16:51, Christian Schneider wrote:

> I am pretty sure you can use it. 
>
> There is an example in enroute:
> https://github.com/osgi/osgi.enroute/tree/master/examples/microservice/rest-app-jpa
>
> If you use the same bundles it should work.
> We can create a karaf feature in the aries-tx-control repo for it to
> make it easier to install.
>
> Christian
>
> Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto
> <[hidden email] <mailto:[hidden email]>>:
>
>     Hi,
>
>     Is it possible to use Transaction Control Service Specification with
>     Karaf?
>
>     https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html
>
>
>     Any good example or tutorial?
>
>     (I am currently using Aries JPA Template, but I would like to move
>     on to use the standard)
>
>     Best regards,
>     Alex soto
>
>
>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

Alex Soto
I tried adapting the EnRoute example to use with Karaf some months ago without success. It was more difficult than I could handle, so I ended up using Aries JpaTemplate.  I am revisiting this now, because I have seen issues with Derby where the transaction is not being rolled back, and I thought it may be time to migrate it.  Any help getting this to work on Karaf would be greatly appreciated.

Best regards,
Alex soto




On Feb 5, 2019, at 10:53 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

I'm volunteer to add the features repository in aries-tx-control. That
would be helpful in Karaf.

Regards
JB

On 05/02/2019 16:51, Christian Schneider wrote:
I am pretty sure you can use it. 

There is an example in enroute:
https://github.com/osgi/osgi.enroute/tree/master/examples/microservice/rest-app-jpa

If you use the same bundles it should work.
We can create a karaf feature in the aries-tx-control repo for it to
make it easier to install.

Christian

Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto
<[hidden email] <mailto:[hidden email]>>:

   Hi,

   Is it possible to use Transaction Control Service Specification with
   Karaf?

   https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html


   Any good example or tutorial?

   (I am currently using Aries JPA Template, but I would like to move
   on to use the standard)

   Best regards,
   Alex soto






--
--
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com


--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

jbonofre
Hi,

We did the improvement in Aries JAXRS whiteboard to work in Karaf, so
after the releases, I think I can tackle that ;)

Regards
JB

On 05/02/2019 16:59, Alex Soto wrote:

> I tried adapting the EnRoute example to use with Karaf some months ago
> without success. It was more difficult than I could handle, so I ended
> up using Aries JpaTemplate.  I am revisiting this now, because I have
> seen issues with Derby where the transaction is not being rolled back,
> and I thought it may be time to migrate it.  Any help getting this to
> work on Karaf would be greatly appreciated.
>
> Best regards,
> Alex soto
>
>
>
>
>> On Feb 5, 2019, at 10:53 AM, Jean-Baptiste Onofré <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> I'm volunteer to add the features repository in aries-tx-control. That
>> would be helpful in Karaf.
>>
>> Regards
>> JB
>>
>> On 05/02/2019 16:51, Christian Schneider wrote:
>>> I am pretty sure you can use it. 
>>>
>>> There is an example in enroute:
>>> https://github.com/osgi/osgi.enroute/tree/master/examples/microservice/rest-app-jpa
>>>
>>> If you use the same bundles it should work.
>>> We can create a karaf feature in the aries-tx-control repo for it to
>>> make it easier to install.
>>>
>>> Christian
>>>
>>> Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto
>>> <[hidden email] <mailto:[hidden email]>>:
>>>
>>>    Hi,
>>>
>>>    Is it possible to use Transaction Control Service Specification with
>>>    Karaf?
>>>
>>>    https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html
>>>
>>>
>>>    Any good example or tutorial?
>>>
>>>    (I am currently using Aries JPA Template, but I would like to move
>>>    on to use the standard)
>>>
>>>    Best regards,
>>>    Alex soto
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Computer Scientist
>>> http://www.adobe.com
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email] <mailto:[hidden email]>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

Alex Soto
Thanks, will wait for 4.3.x then.

Best regards,
Alex soto




On Feb 5, 2019, at 11:11 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

Hi,

We did the improvement in Aries JAXRS whiteboard to work in Karaf, so
after the releases, I think I can tackle that ;)

Regards
JB

On 05/02/2019 16:59, Alex Soto wrote:
I tried adapting the EnRoute example to use with Karaf some months ago
without success. It was more difficult than I could handle, so I ended
up using Aries JpaTemplate.  I am revisiting this now, because I have
seen issues with Derby where the transaction is not being rolled back,
and I thought it may be time to migrate it.  Any help getting this to
work on Karaf would be greatly appreciated.

Best regards,
Alex soto




On Feb 5, 2019, at 10:53 AM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>> wrote:

I'm volunteer to add the features repository in aries-tx-control. That
would be helpful in Karaf.

Regards
JB

On 05/02/2019 16:51, Christian Schneider wrote:
I am pretty sure you can use it. 

There is an example in enroute:
https://github.com/osgi/osgi.enroute/tree/master/examples/microservice/rest-app-jpa

If you use the same bundles it should work.
We can create a karaf feature in the aries-tx-control repo for it to
make it easier to install.

Christian

Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto
<[hidden email] <mailto:[hidden email]>>:

   Hi,

   Is it possible to use Transaction Control Service Specification with
   Karaf?

   https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html


   Any good example or tutorial?

   (I am currently using Aries JPA Template, but I would like to move
   on to use the standard)

   Best regards,
   Alex soto






-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com


-- 
Jean-Baptiste Onofré
[hidden email] <[hidden email]>
http://blog.nanthrax.net
Talend - http://www.talend.com


-- 
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

jbonofre
Hi Alex,

Let me check if I can also do it on 4.2.x branch (once it will be
created after the 4.2.3 release).

I will keep you posted.

Regards
JB

On 05/02/2019 17:24, Alex Soto wrote:

> Thanks, will wait for 4.3.x then.
>
> Best regards,
> Alex soto
>
>
>
>
>> On Feb 5, 2019, at 11:11 AM, Jean-Baptiste Onofré <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Hi,
>>
>> We did the improvement in Aries JAXRS whiteboard to work in Karaf, so
>> after the releases, I think I can tackle that ;)
>>
>> Regards
>> JB
>>
>> On 05/02/2019 16:59, Alex Soto wrote:
>>> I tried adapting the EnRoute example to use with Karaf some months ago
>>> without success. It was more difficult than I could handle, so I ended
>>> up using Aries JpaTemplate.  I am revisiting this now, because I have
>>> seen issues with Derby where the transaction is not being rolled back,
>>> and I thought it may be time to migrate it.  Any help getting this to
>>> work on Karaf would be greatly appreciated.
>>>
>>> Best regards,
>>> Alex soto
>>>
>>>
>>>
>>>
>>>> On Feb 5, 2019, at 10:53 AM, Jean-Baptiste Onofré <[hidden email]
>>>> <mailto:[hidden email]>
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>> I'm volunteer to add the features repository in aries-tx-control. That
>>>> would be helpful in Karaf.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 05/02/2019 16:51, Christian Schneider wrote:
>>>>> I am pretty sure you can use it. 
>>>>>
>>>>> There is an example in enroute:
>>>>> https://github.com/osgi/osgi.enroute/tree/master/examples/microservice/rest-app-jpa
>>>>>
>>>>> If you use the same bundles it should work.
>>>>> We can create a karaf feature in the aries-tx-control repo for it to
>>>>> make it easier to install.
>>>>>
>>>>> Christian
>>>>>
>>>>> Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto
>>>>> <[hidden email] <mailto:[hidden email]>>:
>>>>>
>>>>>    Hi,
>>>>>
>>>>>    Is it possible to use Transaction Control Service Specification with
>>>>>    Karaf?
>>>>>
>>>>>    https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html
>>>>>
>>>>>
>>>>>    Any good example or tutorial?
>>>>>
>>>>>    (I am currently using Aries JPA Template, but I would like to move
>>>>>    on to use the standard)
>>>>>
>>>>>    Best regards,
>>>>>    Alex soto
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> -- 
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>>
>>>>> Computer Scientist
>>>>> http://www.adobe.com
>>>>>
>>>>
>>>> -- 
>>>> Jean-Baptiste Onofré
>>>> [hidden email]
>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>>> Talend - http://www.talend.com <http://www.talend.com/>
>>>
>>
>> -- 
>> Jean-Baptiste Onofré
>> [hidden email] <mailto:[hidden email]>
>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>> Talend - http://www.talend.com <http://www.talend.com/>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

Alex Soto
That would be ideal, thanks!


Best regards,
Alex soto




On Feb 5, 2019, at 11:28 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

Hi Alex,

Let me check if I can also do it on 4.2.x branch (once it will be
created after the 4.2.3 release).

I will keep you posted.

Regards
JB

On 05/02/2019 17:24, Alex Soto wrote:
Thanks, will wait for 4.3.x then.

Best regards,
Alex soto




On Feb 5, 2019, at 11:11 AM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>> wrote:

Hi,

We did the improvement in Aries JAXRS whiteboard to work in Karaf, so
after the releases, I think I can tackle that ;)

Regards
JB

On 05/02/2019 16:59, Alex Soto wrote:
I tried adapting the EnRoute example to use with Karaf some months ago
without success. It was more difficult than I could handle, so I ended
up using Aries JpaTemplate.  I am revisiting this now, because I have
seen issues with Derby where the transaction is not being rolled back,
and I thought it may be time to migrate it.  Any help getting this to
work on Karaf would be greatly appreciated.

Best regards,
Alex soto




On Feb 5, 2019, at 10:53 AM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>
<[hidden email]>> wrote:

I'm volunteer to add the features repository in aries-tx-control. That
would be helpful in Karaf.

Regards
JB

On 05/02/2019 16:51, Christian Schneider wrote:
I am pretty sure you can use it. 

There is an example in enroute:
https://github.com/osgi/osgi.enroute/tree/master/examples/microservice/rest-app-jpa

If you use the same bundles it should work.
We can create a karaf feature in the aries-tx-control repo for it to
make it easier to install.

Christian

Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto
<[hidden email] <mailto:[hidden email]>>:

   Hi,

   Is it possible to use Transaction Control Service Specification with
   Karaf?

   https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html


   Any good example or tutorial?

   (I am currently using Aries JPA Template, but I would like to move
   on to use the standard)

   Best regards,
   Alex soto






-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com


-- 
Jean-Baptiste Onofré
[hidden email]
<mailto:[hidden email]> <mailto:[hidden email]>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
Talend - http://www.talend.com <http://www.talend.com/>


-- 
Jean-Baptiste Onofré
[hidden email] <[hidden email]>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
Talend - http://www.talend.com <http://www.talend.com/>


--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

Tim Jones
In reply to this post by Alex Soto
Hi Alex,

yes it is possible to use tx-control with Karaf, we have been using it on
v4.0.5 in our production system for about 18 months with no issues. One of
the main reasons we use tx-control is that is it 'backed' by a standard.
Rightly or wrongly we also didn't have confidence in Aries JPA Template at
the time we were considering transaction managment solutions to manage our
transactions in a production environment (perhaps this was misguided) but we
were concerned that there were few integrated tests for that project where
as there are over 2000 lines of test code for tx-control which demonstrate
sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
commit, rollback depending upon exception type and much more.

I think the enRoute project has some examples
https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and
the tx-control test code is worth looking at.

Tim



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

jbonofre
Thanks for the feedback Tim.

I created the following Jira to add a example about tx in general and
tx-control in particular:

https://issues.apache.org/jira/browse/KARAF-6140

By hte way, before the end of this week, I will send the first action of
the "kloud initiative". Especially, I will send a proposal to simplify
the developer perspective.

Regards
JB

On 06/02/2019 21:16, Tim Jones wrote:

> Hi Alex,
>
> yes it is possible to use tx-control with Karaf, we have been using it on
> v4.0.5 in our production system for about 18 months with no issues. One of
> the main reasons we use tx-control is that is it 'backed' by a standard.
> Rightly or wrongly we also didn't have confidence in Aries JPA Template at
> the time we were considering transaction managment solutions to manage our
> transactions in a production environment (perhaps this was misguided) but we
> were concerned that there were few integrated tests for that project where
> as there are over 2000 lines of test code for tx-control which demonstrate
> sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
> commit, rollback depending upon exception type and much more.
>
> I think the enRoute project has some examples
> https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and
> the tx-control test code is worth looking at.
>
> Tim
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

Alex Soto
In reply to this post by Tim Jones
Actually, I took a stab at this again since I had some spare time now.  I am almost done. It looks promising.

The only question I have is about the entity manager.  In the examples, I see an entity manager is obtained in the activate method, and used for the rest of the life of the component:

private EntityManager em;

@Activate
void init() {
em = provider.getResource(txControl);
}


Is this safe in a multi threaded environment? I expect the component to be called concurrently. 
Section 127.3.3 of OSGi Companion states that "An Entity Manager is intended to be used by a single session, it is not thread safe.” So I am confused since all examples seem to be ignoring this.


Best regards,
Alex soto




On Feb 6, 2019, at 3:16 PM, Tim Jones <[hidden email]> wrote:

Hi Alex,

yes it is possible to use tx-control with Karaf, we have been using it on
v4.0.5 in our production system for about 18 months with no issues. One of
the main reasons we use tx-control is that is it 'backed' by a standard.
Rightly or wrongly we also didn't have confidence in Aries JPA Template at
the time we were considering transaction managment solutions to manage our
transactions in a production environment (perhaps this was misguided) but we
were concerned that there were few integrated tests for that project where
as there are over 2000 lines of test code for tx-control which demonstrate
sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
commit, rollback depending upon exception type and much more.

I think the enRoute project has some examples
https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and
the tx-control test code is worth looking at.

Tim



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

Tim Ward-2
The relevant specification for learning about scoped resources (which is what the ResourceProvider gives you) is the Transaction Control Specification. In this case your question is covered by Section 147.2.5 Multi Threading

Scoped resources are always thread safe and designed to be singleton objects used across multiple scopes. The underlying scoped resource implementation then delegates to a real resource instance that is bound to the current scope. The result is that the real resource never sees multi-threaded access (a scope is bound to a single thread) and that you never need to worry about creating/closing the resource because the “real resource” is automatically created (or retrieved from a pool) on first use within a scope and then closed (or returned to the pool) when the scope finishes. 

Best Regards,

Tim

On 6 Feb 2019, at 22:14, Alex Soto <[hidden email]> wrote:

Actually, I took a stab at this again since I had some spare time now.  I am almost done. It looks promising.

The only question I have is about the entity manager.  In the examples, I see an entity manager is obtained in the activate method, and used for the rest of the life of the component:

private EntityManager em;

@Activate
void init() {
em = provider.getResource(txControl);
}


Is this safe in a multi threaded environment? I expect the component to be called concurrently. 
Section 127.3.3 of OSGi Companion states that "An Entity Manager is intended to be used by a single session, it is not thread safe.” So I am confused since all examples seem to be ignoring this.


Best regards,
Alex soto




On Feb 6, 2019, at 3:16 PM, Tim Jones <[hidden email]> wrote:

Hi Alex,

yes it is possible to use tx-control with Karaf, we have been using it on
v4.0.5 in our production system for about 18 months with no issues. One of
the main reasons we use tx-control is that is it 'backed' by a standard.
Rightly or wrongly we also didn't have confidence in Aries JPA Template at
the time we were considering transaction managment solutions to manage our
transactions in a production environment (perhaps this was misguided) but we
were concerned that there were few integrated tests for that project where
as there are over 2000 lines of test code for tx-control which demonstrate
sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
commit, rollback depending upon exception type and much more.

I think the enRoute project has some examples
https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and
the tx-control test code is worth looking at.

Tim



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html


Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

Alex Soto
Tim: thank you for the clarification.

Best regards,
Alex soto




On Feb 6, 2019, at 4:40 PM, Tim Ward <[hidden email]> wrote:

The relevant specification for learning about scoped resources (which is what the ResourceProvider gives you) is the Transaction Control Specification. In this case your question is covered by Section 147.2.5 Multi Threading

Scoped resources are always thread safe and designed to be singleton objects used across multiple scopes. The underlying scoped resource implementation then delegates to a real resource instance that is bound to the current scope. The result is that the real resource never sees multi-threaded access (a scope is bound to a single thread) and that you never need to worry about creating/closing the resource because the “real resource” is automatically created (or retrieved from a pool) on first use within a scope and then closed (or returned to the pool) when the scope finishes. 

Best Regards,

Tim

On 6 Feb 2019, at 22:14, Alex Soto <[hidden email]> wrote:

Actually, I took a stab at this again since I had some spare time now.  I am almost done. It looks promising.

The only question I have is about the entity manager.  In the examples, I see an entity manager is obtained in the activate method, and used for the rest of the life of the component:

private EntityManager em;

@Activate
void init() {
em = provider.getResource(txControl);
}


Is this safe in a multi threaded environment? I expect the component to be called concurrently. 
Section 127.3.3 of OSGi Companion states that "An Entity Manager is intended to be used by a single session, it is not thread safe.” So I am confused since all examples seem to be ignoring this.


Best regards,
Alex soto




On Feb 6, 2019, at 3:16 PM, Tim Jones <[hidden email]> wrote:

Hi Alex,

yes it is possible to use tx-control with Karaf, we have been using it on
v4.0.5 in our production system for about 18 months with no issues. One of
the main reasons we use tx-control is that is it 'backed' by a standard.
Rightly or wrongly we also didn't have confidence in Aries JPA Template at
the time we were considering transaction managment solutions to manage our
transactions in a production environment (perhaps this was misguided) but we
were concerned that there were few integrated tests for that project where
as there are over 2000 lines of test code for tx-control which demonstrate
sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
commit, rollback depending upon exception type and much more.

I think the enRoute project has some examples
https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and
the tx-control test code is worth looking at.

Tim



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html



Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

Alex Soto
In reply to this post by Tim Ward-2
I am wondering if it makes sense to create the scoped EntityManager as a singleton service to be then @Referenced by the various repositories.   I have various repository classes that need the EntityManager, all would need to have some code like this:

@Reference(target = "(osgi.unit.name=myPersistenUnit)")
private JPAEntityManagerProvider provider;

private EntityManager em;

@Activate
void init() {
  em = provider.getResource(txControl);
}


So each Repository component creates its own Scoped EntityManager. Does it make sense to have one component in the application that creates a single EM and have the various repositories use that one from the Service Registry?

Best regards,
Alex soto




On Feb 6, 2019, at 4:40 PM, Tim Ward <[hidden email]> wrote:

The relevant specification for learning about scoped resources (which is what the ResourceProvider gives you) is the Transaction Control Specification. In this case your question is covered by Section 147.2.5 Multi Threading

Scoped resources are always thread safe and designed to be singleton objects used across multiple scopes. The underlying scoped resource implementation then delegates to a real resource instance that is bound to the current scope. The result is that the real resource never sees multi-threaded access (a scope is bound to a single thread) and that you never need to worry about creating/closing the resource because the “real resource” is automatically created (or retrieved from a pool) on first use within a scope and then closed (or returned to the pool) when the scope finishes. 

Best Regards,

Tim

On 6 Feb 2019, at 22:14, Alex Soto <[hidden email]> wrote:

Actually, I took a stab at this again since I had some spare time now.  I am almost done. It looks promising.

The only question I have is about the entity manager.  In the examples, I see an entity manager is obtained in the activate method, and used for the rest of the life of the component:

private EntityManager em;

@Activate
void init() {
em = provider.getResource(txControl);
}


Is this safe in a multi threaded environment? I expect the component to be called concurrently. 
Section 127.3.3 of OSGi Companion states that "An Entity Manager is intended to be used by a single session, it is not thread safe.” So I am confused since all examples seem to be ignoring this.


Best regards,
Alex soto




On Feb 6, 2019, at 3:16 PM, Tim Jones <[hidden email]> wrote:

Hi Alex,

yes it is possible to use tx-control with Karaf, we have been using it on
v4.0.5 in our production system for about 18 months with no issues. One of
the main reasons we use tx-control is that is it 'backed' by a standard.
Rightly or wrongly we also didn't have confidence in Aries JPA Template at
the time we were considering transaction managment solutions to manage our
transactions in a production environment (perhaps this was misguided) but we
were concerned that there were few integrated tests for that project where
as there are over 2000 lines of test code for tx-control which demonstrate
sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
commit, rollback depending upon exception type and much more.

I think the enRoute project has some examples
https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and
the tx-control test code is worth looking at.

Tim



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html



Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

Tim Ward-2
Hi,

The model is the way it is quite deliberately, and there are several usage issues with doing what you’re suggesting:

  • It is unclear whether the EntityManager service is a scoped resource (and therefore managed) or not to external users
  • It is unclear which Transaction Control service implementation the scoped resource is attached to (the getResource(txControl) call creates an important link). If you use the wrong Transaction Control implementation (there may be several) then it won’t work properly.
  • It becomes harder to debug what’s going on because there are more “non obvious" links between services

These issues (and a few others) are problems that people hit repeatedly when trying to use DataSources and Transactions together in OSGi. I have seen *many* applications where people did not realise that their carefully set up transactions didn’t roll back because they were using the wrong datasource service, or it had been bound to a different transaction manager than the one they were using to start the transaction.

Therefore, while it is possible to do what you’re suggesting I would *strongly* encourage you not to do it. We’ve been there before and it sucked so hard that it resulted in us creating a whole new specification to fix the problems (namely the Transaction Control specification!).

If you’re able to use Declarative Services 1.4 (you possibly aren’t) then you could simplify your example a little using constructor injection:

private final EntityManager em;
private final TransactionControl txControl;

@Activate
public MyServiceImpl(@Reference(target = "(osgi.unit.name=myPersistenUnit)”) 
JPAEntityManagerProvider provider, @Reference TransactionControl txControl) {
this.txControl = txControl;
em = provider.getResource(txControl);

}

Best Regards,

Tim

On 7 Feb 2019, at 15:02, Alex Soto <[hidden email]> wrote:

I am wondering if it makes sense to create the scoped EntityManager as a singleton service to be then @Referenced by the various repositories.   I have various repository classes that need the EntityManager, all would need to have some code like this:

@Reference(target = "(osgi.unit.name=myPersistenUnit)")
private JPAEntityManagerProvider provider;

private EntityManager em;

@Activate
void init() {
  em = provider.getResource(txControl);
}


So each Repository component creates its own Scoped EntityManager. Does it make sense to have one component in the application that creates a single EM and have the various repositories use that one from the Service Registry?

Best regards,
Alex soto




On Feb 6, 2019, at 4:40 PM, Tim Ward <[hidden email]> wrote:

The relevant specification for learning about scoped resources (which is what the ResourceProvider gives you) is the Transaction Control Specification. In this case your question is covered by Section 147.2.5 Multi Threading

Scoped resources are always thread safe and designed to be singleton objects used across multiple scopes. The underlying scoped resource implementation then delegates to a real resource instance that is bound to the current scope. The result is that the real resource never sees multi-threaded access (a scope is bound to a single thread) and that you never need to worry about creating/closing the resource because the “real resource” is automatically created (or retrieved from a pool) on first use within a scope and then closed (or returned to the pool) when the scope finishes. 

Best Regards,

Tim

On 6 Feb 2019, at 22:14, Alex Soto <[hidden email]> wrote:

Actually, I took a stab at this again since I had some spare time now.  I am almost done. It looks promising.

The only question I have is about the entity manager.  In the examples, I see an entity manager is obtained in the activate method, and used for the rest of the life of the component:

private EntityManager em;

@Activate
void init() {
em = provider.getResource(txControl);
}


Is this safe in a multi threaded environment? I expect the component to be called concurrently. 
Section 127.3.3 of OSGi Companion states that "An Entity Manager is intended to be used by a single session, it is not thread safe.” So I am confused since all examples seem to be ignoring this.


Best regards,
Alex soto




On Feb 6, 2019, at 3:16 PM, Tim Jones <[hidden email]> wrote:

Hi Alex,

yes it is possible to use tx-control with Karaf, we have been using it on
v4.0.5 in our production system for about 18 months with no issues. One of
the main reasons we use tx-control is that is it 'backed' by a standard.
Rightly or wrongly we also didn't have confidence in Aries JPA Template at
the time we were considering transaction managment solutions to manage our
transactions in a production environment (perhaps this was misguided) but we
were concerned that there were few integrated tests for that project where
as there are over 2000 lines of test code for tx-control which demonstrate
sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
commit, rollback depending upon exception type and much more.

I think the enRoute project has some examples
https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and
the tx-control test code is worth looking at.

Tim



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html




Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

Alex Soto
Thank you Tim,  I am glad I asked. 

Best regards,
Alex soto




On Feb 7, 2019, at 9:26 AM, Tim Ward <[hidden email]> wrote:

Hi,

The model is the way it is quite deliberately, and there are several usage issues with doing what you’re suggesting:

  • It is unclear whether the EntityManager service is a scoped resource (and therefore managed) or not to external users
  • It is unclear which Transaction Control service implementation the scoped resource is attached to (the getResource(txControl) call creates an important link). If you use the wrong Transaction Control implementation (there may be several) then it won’t work properly.
  • It becomes harder to debug what’s going on because there are more “non obvious" links between services

These issues (and a few others) are problems that people hit repeatedly when trying to use DataSources and Transactions together in OSGi. I have seen *many* applications where people did not realise that their carefully set up transactions didn’t roll back because they were using the wrong datasource service, or it had been bound to a different transaction manager than the one they were using to start the transaction.

Therefore, while it is possible to do what you’re suggesting I would *strongly* encourage you not to do it. We’ve been there before and it sucked so hard that it resulted in us creating a whole new specification to fix the problems (namely the Transaction Control specification!).

If you’re able to use Declarative Services 1.4 (you possibly aren’t) then you could simplify your example a little using constructor injection:

private final EntityManager em;
private final TransactionControl txControl;

@Activate
public MyServiceImpl(@Reference(target = "(osgi.unit.name=myPersistenUnit)”) 
JPAEntityManagerProvider provider, @Reference TransactionControl txControl) {
this.txControl = txControl;
em = provider.getResource(txControl);

}

Best Regards,

Tim

On 7 Feb 2019, at 15:02, Alex Soto <[hidden email]> wrote:

I am wondering if it makes sense to create the scoped EntityManager as a singleton service to be then @Referenced by the various repositories.   I have various repository classes that need the EntityManager, all would need to have some code like this:

@Reference(target = "(osgi.unit.name=myPersistenUnit)")
private JPAEntityManagerProvider provider;

private EntityManager em;

@Activate
void init() {
  em = provider.getResource(txControl);
}


So each Repository component creates its own Scoped EntityManager. Does it make sense to have one component in the application that creates a single EM and have the various repositories use that one from the Service Registry?

Best regards,
Alex soto




On Feb 6, 2019, at 4:40 PM, Tim Ward <[hidden email]> wrote:

The relevant specification for learning about scoped resources (which is what the ResourceProvider gives you) is the Transaction Control Specification. In this case your question is covered by Section 147.2.5 Multi Threading

Scoped resources are always thread safe and designed to be singleton objects used across multiple scopes. The underlying scoped resource implementation then delegates to a real resource instance that is bound to the current scope. The result is that the real resource never sees multi-threaded access (a scope is bound to a single thread) and that you never need to worry about creating/closing the resource because the “real resource” is automatically created (or retrieved from a pool) on first use within a scope and then closed (or returned to the pool) when the scope finishes. 

Best Regards,

Tim

On 6 Feb 2019, at 22:14, Alex Soto <[hidden email]> wrote:

Actually, I took a stab at this again since I had some spare time now.  I am almost done. It looks promising.

The only question I have is about the entity manager.  In the examples, I see an entity manager is obtained in the activate method, and used for the rest of the life of the component:

private EntityManager em;

@Activate
void init() {
em = provider.getResource(txControl);
}


Is this safe in a multi threaded environment? I expect the component to be called concurrently. 
Section 127.3.3 of OSGi Companion states that "An Entity Manager is intended to be used by a single session, it is not thread safe.” So I am confused since all examples seem to be ignoring this.


Best regards,
Alex soto




On Feb 6, 2019, at 3:16 PM, Tim Jones <[hidden email]> wrote:

Hi Alex,

yes it is possible to use tx-control with Karaf, we have been using it on
v4.0.5 in our production system for about 18 months with no issues. One of
the main reasons we use tx-control is that is it 'backed' by a standard.
Rightly or wrongly we also didn't have confidence in Aries JPA Template at
the time we were considering transaction managment solutions to manage our
transactions in a production environment (perhaps this was misguided) but we
were concerned that there were few integrated tests for that project where
as there are over 2000 lines of test code for tx-control which demonstrate
sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
commit, rollback depending upon exception type and much more.

I think the enRoute project has some examples
https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and
the tx-control test code is worth looking at.

Tim



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html





Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

Tim Ward-2
Not a problem - registering the resource as a service is a simple idea that sounds good. I even advocated it in my book! I then spent 3 years helping people fix the same persistence problems over and over which definitely changed my mind… 

That’s why I (and a bunch of other OSGi Alliance members) have spent the last 3-4 years advocating people do transactions and resources differently. The small amount of boilerplate code is annoying, but it completely eliminates the lifecycle and service linking issues that we used to have with the invisible “joining up” of the old transaction behaviour. The whole thing is much more reliable.

Totally worth it :)

Tim



On 7 Feb 2019, at 15:42, Alex Soto <[hidden email]> wrote:

Thank you Tim,  I am glad I asked. 

Best regards,
Alex soto




On Feb 7, 2019, at 9:26 AM, Tim Ward <[hidden email]> wrote:

Hi,

The model is the way it is quite deliberately, and there are several usage issues with doing what you’re suggesting:

  • It is unclear whether the EntityManager service is a scoped resource (and therefore managed) or not to external users
  • It is unclear which Transaction Control service implementation the scoped resource is attached to (the getResource(txControl) call creates an important link). If you use the wrong Transaction Control implementation (there may be several) then it won’t work properly.
  • It becomes harder to debug what’s going on because there are more “non obvious" links between services

These issues (and a few others) are problems that people hit repeatedly when trying to use DataSources and Transactions together in OSGi. I have seen *many* applications where people did not realise that their carefully set up transactions didn’t roll back because they were using the wrong datasource service, or it had been bound to a different transaction manager than the one they were using to start the transaction.

Therefore, while it is possible to do what you’re suggesting I would *strongly* encourage you not to do it. We’ve been there before and it sucked so hard that it resulted in us creating a whole new specification to fix the problems (namely the Transaction Control specification!).

If you’re able to use Declarative Services 1.4 (you possibly aren’t) then you could simplify your example a little using constructor injection:

private final EntityManager em;
private final TransactionControl txControl;

@Activate
public MyServiceImpl(@Reference(target = "(osgi.unit.name=myPersistenUnit)”) 
JPAEntityManagerProvider provider, @Reference TransactionControl txControl) {
this.txControl = txControl;
em = provider.getResource(txControl);

}

Best Regards,

Tim

On 7 Feb 2019, at 15:02, Alex Soto <[hidden email]> wrote:

I am wondering if it makes sense to create the scoped EntityManager as a singleton service to be then @Referenced by the various repositories.   I have various repository classes that need the EntityManager, all would need to have some code like this:

@Reference(target = "(osgi.unit.name=myPersistenUnit)")
private JPAEntityManagerProvider provider;

private EntityManager em;

@Activate
void init() {
  em = provider.getResource(txControl);
}


So each Repository component creates its own Scoped EntityManager. Does it make sense to have one component in the application that creates a single EM and have the various repositories use that one from the Service Registry?

Best regards,
Alex soto




On Feb 6, 2019, at 4:40 PM, Tim Ward <[hidden email]> wrote:

The relevant specification for learning about scoped resources (which is what the ResourceProvider gives you) is the Transaction Control Specification. In this case your question is covered by Section 147.2.5 Multi Threading

Scoped resources are always thread safe and designed to be singleton objects used across multiple scopes. The underlying scoped resource implementation then delegates to a real resource instance that is bound to the current scope. The result is that the real resource never sees multi-threaded access (a scope is bound to a single thread) and that you never need to worry about creating/closing the resource because the “real resource” is automatically created (or retrieved from a pool) on first use within a scope and then closed (or returned to the pool) when the scope finishes. 

Best Regards,

Tim

On 6 Feb 2019, at 22:14, Alex Soto <[hidden email]> wrote:

Actually, I took a stab at this again since I had some spare time now.  I am almost done. It looks promising.

The only question I have is about the entity manager.  In the examples, I see an entity manager is obtained in the activate method, and used for the rest of the life of the component:

private EntityManager em;

@Activate
void init() {
em = provider.getResource(txControl);
}


Is this safe in a multi threaded environment? I expect the component to be called concurrently. 
Section 127.3.3 of OSGi Companion states that "An Entity Manager is intended to be used by a single session, it is not thread safe.” So I am confused since all examples seem to be ignoring this.


Best regards,
Alex soto




On Feb 6, 2019, at 3:16 PM, Tim Jones <[hidden email]> wrote:

Hi Alex,

yes it is possible to use tx-control with Karaf, we have been using it on
v4.0.5 in our production system for about 18 months with no issues. One of
the main reasons we use tx-control is that is it 'backed' by a standard.
Rightly or wrongly we also didn't have confidence in Aries JPA Template at
the time we were considering transaction managment solutions to manage our
transactions in a production environment (perhaps this was misguided) but we
were concerned that there were few integrated tests for that project where
as there are over 2000 lines of test code for tx-control which demonstrate
sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins,
commit, rollback depending upon exception type and much more.

I think the enRoute project has some examples
https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html and
the tx-control test code is worth looking at.

Tim



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html






Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

maggu2810
In reply to this post by jbonofre
Hi JB,

can you point me to the feature repositories I need to add to Karaf
4.2.6 to use OSGi R7 transaction control and JPA?

Am Di., 5. Feb. 2019 um 16:53 Uhr schrieb Jean-Baptiste Onofré
<[hidden email]>:

>
> I'm volunteer to add the features repository in aries-tx-control. That
> would be helpful in Karaf.
>
> Regards
> JB
>
> On 05/02/2019 16:51, Christian Schneider wrote:
> > I am pretty sure you can use it.
> >
> > There is an example in enroute:
> > https://github.com/osgi/osgi.enroute/tree/master/examples/microservice/rest-app-jpa
> >
> > If you use the same bundles it should work.
> > We can create a karaf feature in the aries-tx-control repo for it to
> > make it easier to install.
> >
> > Christian
> >
> > Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto
> > <[hidden email] <mailto:[hidden email]>>:
> >
> >     Hi,
> >
> >     Is it possible to use Transaction Control Service Specification with
> >     Karaf?
> >
> >     https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html
> >
> >
> >     Any good example or tutorial?
> >
> >     (I am currently using Aries JPA Template, but I would like to move
> >     on to use the standard)
> >
> >     Best regards,
> >     Alex soto
> >
> >
> >
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
> >
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf and Transaction Control Service Specification

maggu2810
Hi,

did you see my message?
Is the feature still in progress or is it just me that did not find it?

Am Mo., 22. Juli 2019 um 13:03 Uhr schrieb Markus Rathgeb <[hidden email]>:

>
> Hi JB,
>
> can you point me to the feature repositories I need to add to Karaf
> 4.2.6 to use OSGi R7 transaction control and JPA?
>
> Am Di., 5. Feb. 2019 um 16:53 Uhr schrieb Jean-Baptiste Onofré
> <[hidden email]>:
> >
> > I'm volunteer to add the features repository in aries-tx-control. That
> > would be helpful in Karaf.
> >
> > Regards
> > JB
> >
> > On 05/02/2019 16:51, Christian Schneider wrote:
> > > I am pretty sure you can use it.
> > >
> > > There is an example in enroute:
> > > https://github.com/osgi/osgi.enroute/tree/master/examples/microservice/rest-app-jpa
> > >
> > > If you use the same bundles it should work.
> > > We can create a karaf feature in the aries-tx-control repo for it to
> > > make it easier to install.
> > >
> > > Christian
> > >
> > > Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto
> > > <[hidden email] <mailto:[hidden email]>>:
> > >
> > >     Hi,
> > >
> > >     Is it possible to use Transaction Control Service Specification with
> > >     Karaf?
> > >
> > >     https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html
> > >
> > >
> > >     Any good example or tutorial?
> > >
> > >     (I am currently using Aries JPA Template, but I would like to move
> > >     on to use the standard)
> > >
> > >     Best regards,
> > >     Alex soto
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > --
> > > Christian Schneider
> > > http://www.liquid-reality.de
> > >
> > > Computer Scientist
> > > http://www.adobe.com
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > [hidden email]
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
12