Re: [osgi-dev] Valid coordinator scenario?

[BJ Hargrave]

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 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: 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);
>
> 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 Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev