Re: [osgi-dev] Valid coordinator scenario?
Perfect! Then blueprint will hold the strong reference for you and pass it back to the post call to either end or fail the coordination. --BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com - Original message -From: Christian Schneider ch...@die-schneider.netSent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List osgi-dev@mail.osgi.orgCc:Subject: Re: [osgi-dev] Valid coordinator scenario?Date: Tue, Aug 4, 2015 3:22 AM Actually after talking to Peter I just found a much simpler solution when I tried to explain the problem.I am using the Aries blueprint interceptor interface:https://github.com/apache/aries/blob/trunk/blueprint/blueprint-parser/src/main/java/org/apache/aries/blueprint/Interceptor.javaIt allows to return an object in precall. So I can simply return the coordination there and I do not need to store it in a thread local.ChristianOn 03.08.2015 23:23, BJ Hargrave wrote: Yes, you need to do something to hold a strong reference to the coordination. But you also need to make sure you always clean up so there is no case where a strong reference is never cleaned up. I don't know anything about your use case. --BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com --Christian Schneiderhttp://www.liquid-reality.deOpen Source Architecthttp://www.talend.com ___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
Hi BJ, I thought I had explained it earlier but looking through the mails I did not :-) Basically my case is what Aries Transaction and Aries JPA need for blueprint support. Each implement a blueprint Interceptor that is called before and after the user bean. Both can begin a Coordination before the user code and close it afterwards. When an EntityManager is requested the first time for a persistence unit on a thread it is registered with the outermost coordination as a participant. So it can be closed when the coordination ends. With my first approach I always opened and closed a new Coordination as I then did not need to manage it. As I now know I had to keep a reference myself I can maybe do it differently. The nice thing about always opening and closing the Coordination was that the Coordinator manages the Coordination count for me. Now when I have to keep the references myself I will have to make sure I keep track of all of them myself. I wonder if I can just open one Coordination and also store a counter how deeply nested the call is. Then when I reach the outermost closing side I can close it. This was roughly how I did this without the Coordinator service. Christian Am 03.08.2015 um 23:23 schrieb BJ Hargrave: Yes, you need to do something to hold a strong reference to the coordination. But you also need to make sure you always clean up so there is no case where a strong reference is never cleaned up. I don't know anything about your use case. -- BJ Hargrave Senior Technical Staff Member, IBM // office: +1 386 848 1781 OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 hargr...@us.ibm.com - Original message - From: Christian Schneider ch...@die-schneider.net Sent by: osgi-dev-boun...@mail.osgi.org To: OSGi Developer Mail List osgi-dev@mail.osgi.org Cc: Subject: Re: [osgi-dev] Valid coordinator scenario? Date: Mon, Aug 3, 2015 5:11 PM So what is the preferred solution for my use case? I will need to push the coorrdination on the stack as this is the only way for other modules on the thread to find it. Pop seems to be a bad idea because of the problem of maybe getting a different coordination. So if I know my code is only called once on this thread I should be able to use a simple thread local: ThreadLocalCoordination coordination; In my interceptor before the user code: coordination.set(coordinator.begin()); In my interceptor after the user code: coordination.get().end(); If the code can be called more than once per thread I would need to use a Stack. Does that make sense? Christian On 03.08.2015 22:00, BJ Hargrave wrote: In that code snippet, the call to gc() is stand in for other code which could trigger a gc. And it is also possible that this other code alters the coordination stack (fails the coordination; coordination times out; ...), so the pop() call may not return the coordination began in the first line. So one really does need to keep the began coordination in a local variable to ensure you are attempting to end the same coordination you began. That is, the code snippet is broken in multiple ways. -- BJ Hargrave Senior Technical Staff Member, IBM // office: +1 386 848 1781 OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 hargr...@us.ibm.com mailto:hargr...@us.ibm.com -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
Actually after talking to Peter I just found a much simpler solution when I tried to explain the problem. I am using the Aries blueprint interceptor interface: https://github.com/apache/aries/blob/trunk/blueprint/blueprint-parser/src/main/java/org/apache/aries/blueprint/Interceptor.java It allows to return an object in precall. So I can simply return the coordination there and I do not need to store it in a thread local. Christian On 03.08.2015 23:23, BJ Hargrave wrote: Yes, you need to do something to hold a strong reference to the coordination. But you also need to make sure you always clean up so there is no case where a strong reference is never cleaned up. I don't know anything about your use case. -- BJ Hargrave Senior Technical Staff Member, IBM // office: +1 386 848 1781 OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 hargr...@us.ibm.com -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
Hi Christian, +1 (it's actually what I wanted to propose as well). Regards JB On 08/04/2015 09:21 AM, Christian Schneider wrote: Actually after talking to Peter I just found a much simpler solution when I tried to explain the problem. I am using the Aries blueprint interceptor interface: https://github.com/apache/aries/blob/trunk/blueprint/blueprint-parser/src/main/java/org/apache/aries/blueprint/Interceptor.java It allows to return an object in precall. So I can simply return the coordination there and I do not need to store it in a thread local. Christian On 03.08.2015 23:23, BJ Hargrave wrote: Yes, you need to do something to hold a strong reference to the coordination. But you also need to make sure you always clean up so there is no case where a strong reference is never cleaned up. I don't know anything about your use case. -- BJ Hargrave Senior Technical Staff Member, IBM // office: +1 386 848 1781 OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 hargr...@us.ibm.com -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
Yes, you need to do something to hold a strong reference to the coordination. But you also need to make sure you always clean up so there is no case where a strong reference is never cleaned up. I don't know anything about your use case. --BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com - Original message -From: Christian Schneider ch...@die-schneider.netSent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List osgi-dev@mail.osgi.orgCc:Subject: Re: [osgi-dev] Valid coordinator scenario?Date: Mon, Aug 3, 2015 5:11 PM So what is the preferred solution for my use case?I will need to push the coorrdination on the stack as this is the only way for other modules on the thread to find it.Pop seems to be a bad idea because of the problem of maybe getting a different coordination.So if I know my code is only called once on this thread I should be able to use a simple thread local:ThreadLocalCoordination coordination;In my interceptor before the user code:coordination.set(coordinator.begin());In my interceptor after the user code:coordination.get().end();If the code can be called more than once per thread I would need to use a Stack.Does that make sense?ChristianOn 03.08.2015 22:00, BJ Hargrave wrote: In that code snippet, the call to gc() is stand in for other code which could trigger a gc. And it is also possible that this other code alters the coordination stack (fails the coordination; coordination times out; ...), so the pop() call may not return the coordination began in the first line. So one really does need to keep the began coordination in a local variable to ensure you are attempting to end the same coordination you began. That is, the code snippet is broken in multiple ways. --BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com --Christian Schneiderhttp://www.liquid-reality.deOpen Source Architecthttp://www.talend.com ___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
I've created an OSGi issue to clarify whether below snippet is supposed to always work and after discussing this with BJ, that code is bound to fail as there is no strong reference to the coordination. The spec and the CT hint that the thread local (or equivalent construct) which holds the coordination in the implementation must be a weak reference. Therefore with the example below, no one is holding a strong reference to the coordination which then allows it to be garbage collected. Regards Carsten Am 31.07.15 um 04:48 schrieb Carsten Ziegeler: Hi, Christian brought up an interesting scenario for using the coordinator. The question is, if the following is a valid scenario: coordinator.begin(test, 0); System.gc(); coordinator.pop().end(); (Of course no one will do a gc() call in his code, its just for demonstrational purposes) The coordination is bound to the thread, but no reference is held. Should the coordination be garbage collected? Looking at the CT it seems, the answer is yes. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
So what is the preferred solution for my use case? I will need to push the coorrdination on the stack as this is the only way for other modules on the thread to find it. Pop seems to be a bad idea because of the problem of maybe getting a different coordination. So if I know my code is only called once on this thread I should be able to use a simple thread local: ThreadLocalCoordination coordination; In my interceptor before the user code: coordination.set(coordinator.begin()); In my interceptor after the user code: coordination.get().end(); If the code can be called more than once per thread I would need to use a Stack. Does that make sense? Christian On 03.08.2015 22:00, BJ Hargrave wrote: In that code snippet, the call to gc() is stand in for other code which could trigger a gc. And it is also possible that this other code alters the coordination stack (fails the coordination; coordination times out; ...), so the pop() call may not return the coordination began in the first line. So one really does need to keep the began coordination in a local variable to ensure you are attempting to end the same coordination you began. That is, the code snippet is broken in multiple ways. -- BJ Hargrave Senior Technical Staff Member, IBM // office: +1 386 848 1781 OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 hargr...@us.ibm.com -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
In that code snippet, the call to gc() is stand in for other code which could trigger a gc. And it is also possible that this other code alters the coordination stack (fails the coordination; coordination times out; ...), so the pop() call may not return the coordination began in the first line.
So one really does need to keep the began coordination in a local variable to ensure you are attempting to end the same coordination you began. That is, the code snippet is broken in multiple ways.
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
- Original message -From: chris.g...@kiffer.beSent by: osgi-dev-boun...@mail.osgi.orgTo: "OSGi Developer Mail List" osgi-dev@mail.osgi.orgCc:Subject: Re: [osgi-dev] Valid coordinator scenario?Date: Mon, Aug 3, 2015 3:37 PM
To me this is less bad than having the coordination hang around for who-knows- how- long in a ThreadLocal (or similar), but tastes may vary. I've created an OSGi issue to clarify whether below snippet is supposed to always work and after discussing this with BJ, that code is bound to fail as there is no strong reference to the coordination. The spec and the CT hint that the thread local (or equivalent construct) which holds the coordination in the implementation must be a weak reference. Therefore with the example below, no one is holding a strong reference to the coordination which then allows it to be garbage collected. Regards Carsten Am 31.07.15 um 04:48 schrieb Carsten Ziegeler: Hi, Christian brought up an interesting scenario for using the coordinator. The question is, if the following is a valid scenario: coordinator.begin("test", 0); System.gc(); coordinator.pop().end(); (Of course no one will do a gc() call in his code, its just for demonstrational purposes) The coordination is bound to the thread, but no reference is held. Should the coordination be garbage collected? Looking at the CT it seems, the answer is yes. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
To me this is less bad than having the coordination hang around for who- knows- how- long in a ThreadLocal (or similar), but tastes may vary. I've created an OSGi issue to clarify whether below snippet is supposed to always work and after discussing this with BJ, that code is bound to fail as there is no strong reference to the coordination. The spec and the CT hint that the thread local (or equivalent construct) which holds the coordination in the implementation must be a weak reference. Therefore with the example below, no one is holding a strong reference to the coordination which then allows it to be garbage collected. Regards Carsten Am 31.07.15 um 04:48 schrieb Carsten Ziegeler: Hi, Christian brought up an interesting scenario for using the coordinator. The question is, if the following is a valid scenario: coordinator.begin(test, 0); System.gc(); coordinator.pop().end(); (Of course no one will do a gc() call in his code, its just for demonstrational purposes) The coordination is bound to the thread, but no reference is held. Should the coordination be garbage collected? Looking at the CT it seems, the answer is yes. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
I think it is impossible to implement Coordinator without having a strong reference to all active Coordination’s, how could pop() otherwise return the current coordination? And the reflection API has the same implications. So the answer is clearly yes. That said, this way you loose an extra safety check that nobody screwed up downstream … Kind regards, Peter Kriens On 31 jul. 2015, at 11:48, Carsten Ziegeler cziege...@apache.org wrote: Hi, Christian brought up an interesting scenario for using the coordinator. The question is, if the following is a valid scenario: coordinator.begin(test, 0); System.gc(); coordinator.pop().end(); (Of course no one will do a gc() call in his code, its just for demonstrational purposes) The coordination is bound to the thread, but no reference is held. Should the coordination be garbage collected? Looking at the CT it seems, the answer is yes. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
This is why the usage model is
begin coordination;
try {
do something that should be coordinated;
} finally {
end coordination;
}
The finally ensures the coordination is not left forever in a thread local.
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
- Original message -From: Christian Schneider ch...@die-schneider.netSent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List osgi-dev@mail.osgi.orgCc:Subject: Re: [osgi-dev] Valid coordinator scenario?Date: Fri, Jul 31, 2015 8:57 AM
On 31.07.2015 14:30, Carsten Ziegeler wrote: Am 31.07.15 um 14:24 schrieb Peter Kriens: I think it is impossible to implement Coordinator without having a strong reference to all active Coordination’s, how could pop() otherwise return the current coordination? And the reflection API has the same implications. So the answer is clearly yes. That said, this way you loose an extra safety check that nobody screwed up downstream … Ok, if the answer is yes, then this coordination might stay around forever (or until that thread dies), e.g. if I just do coordinator.begin("test", 0); CarstenYes .. this is a disadvantage.The problem though without this feature would be that I would need myown thread local to keep the coordinations I use.For example look into this scenario:serviceA - serviceB - RepositoryCserviceA and serviceB and RepositoryC define @Transactional.I have an interceptor that handles all the beans. It will start acoordination before calling the real method and end it after the callcomes back.So if I would not use the stack based coordinator API I would have threelevels of coordinations in the same thread in my example that I have totrack. So I would have tocreate my own thread local with a Stack and store the coordinationsthere. In the end I would have the same problem as with thecoordinator.begin api.So I agree that it is risky if you are not careful with ending thecoordinations but I do not see a better way to do it.Christian--Christian Schneiderhttp://www.liquid-reality.deOpen Source Architecthttp://www.talend.com___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
Yes, just like any other thing held in a threadlocal.
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
- Original message -From: Carsten Ziegeler cziege...@apache.orgSent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List osgi-dev@mail.osgi.orgCc:Subject: Re: [osgi-dev] Valid coordinator scenario?Date: Fri, Jul 31, 2015 8:30 AM
Am 31.07.15 um 14:24 schrieb Peter Kriens: I think it is impossible to implement Coordinator without having a strong reference to all active Coordination’s, how could pop() otherwise return the current coordination? And the reflection API has the same implications. So the answer is clearly yes. That said, this way you loose an extra safety check that nobody screwed up downstream …Ok, if the answer is yes, then this coordination might stay aroundforever (or until that thread dies), e.g. if I just docoordinator.begin("test", 0);Carsten--Carsten ZiegelerAdobe Research Switzerlandcziege...@apache.org___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
Am 31.07.15 um 14:24 schrieb Peter Kriens: I think it is impossible to implement Coordinator without having a strong reference to all active Coordination’s, how could pop() otherwise return the current coordination? And the reflection API has the same implications. So the answer is clearly yes. That said, this way you loose an extra safety check that nobody screwed up downstream … Ok, if the answer is yes, then this coordination might stay around forever (or until that thread dies), e.g. if I just do coordinator.begin(test, 0); Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Valid coordinator scenario?
On 31.07.2015 14:30, Carsten Ziegeler wrote: Am 31.07.15 um 14:24 schrieb Peter Kriens: I think it is impossible to implement Coordinator without having a strong reference to all active Coordination’s, how could pop() otherwise return the current coordination? And the reflection API has the same implications. So the answer is clearly yes. That said, this way you loose an extra safety check that nobody screwed up downstream … Ok, if the answer is yes, then this coordination might stay around forever (or until that thread dies), e.g. if I just do coordinator.begin(test, 0); Carsten Yes .. this is a disadvantage. The problem though without this feature would be that I would need my own thread local to keep the coordinations I use. For example look into this scenario: serviceA - serviceB - RepositoryC serviceA and serviceB and RepositoryC define @Transactional. I have an interceptor that handles all the beans. It will start a coordination before calling the real method and end it after the call comes back. So if I would not use the stack based coordinator API I would have three levels of coordinations in the same thread in my example that I have to track. So I would have to create my own thread local with a Stack and store the coordinations there. In the end I would have the same problem as with the coordinator.begin api. So I agree that it is risky if you are not careful with ending the coordinations but I do not see a better way to do it. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Valid coordinator scenario?
Hi, Christian brought up an interesting scenario for using the coordinator. The question is, if the following is a valid scenario: coordinator.begin(test, 0); System.gc(); coordinator.pop().end(); (Of course no one will do a gc() call in his code, its just for demonstrational purposes) The coordination is bound to the thread, but no reference is held. Should the coordination be garbage collected? Looking at the CT it seems, the answer is yes. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
