aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Do we really need Quiesce support?
Date Fri, 13 Feb 2015 17:25:49 GMT
Many thanks for the explanations.

For JPA I think I now understand what we need to achieve. As soon as a 
persistence unit bundle is quiesced no new EMs should be created.
The opened EMs of the persistence bundle are closed when all calls that 
use them are finished. Then when all those EMs are closed the quiesce
operation reports that it is finished.

I hope this is stated correctly.

Btw. the reason why I want to really understand this in detail is that I 
am planning a bigger redesign of the jpa code. So I want to make sure I 
understand the current requirements and
also try to slim them down wherever possible.


On 13.02.2015 17:56, Jeremy Hughes wrote:
> I've been digging around in my memory. The Quiesce capability is a like a
> soft-stop. It's a generic capability that is enforced differently depending
> on the context. It's more normal for an extender to implement the
> QuiesceParticipant rather than an individual bundle. In the case of the
> Blueprint extender, in flight service calls are allowed to finish - they're
> counted in and counted out - and no new calls are allowed. When there are
> no in flight service calls, the bundle is told to stop. The Blueprint
> bundle itself doesn't know this is happening which is a key design point.
> In the case of JPA, I believe the extender ensures no new Entity Managers
> are created - so similar to the Blueprint case. But it's been a while since
> I looked at this.
> Hope that helps.
> Jeremy

Christian Schneider

Open Source Architect

View raw message