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
[email protected]
----- Original message -----
From: Christian Schneider <[email protected]>
Sent by: [email protected]
To: OSGi Developer Mail List <[email protected]>
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:
ThreadLocal<Coordination> 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
[email protected] <mailto:[email protected]>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
