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
