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 11:23:56 GMT
On 13.02.2015 11:58, Guillaume Nodet wrote:
> Your example expects a simple restart of the service, I'm talking about an
> update/refresh of the bundle.
> But even restarting the service, if the service is an EntityManager, that
> does not work afaik : you can't just switch it in the middle of your
> processing (what you've already done with the JDBC connection in the
> context of your transaction can't be propagated to a new connection).
You are right about a service that provides EntityManger instances. The 
problem here is that the service is not really stateless which makes it 
much harder to manage.
For a normal EntityManagerFactory (like provided by jpa.container) this 
should not apply as the EntityManager is under control of the client bundle.

In case of jpa.container.context there probably is a problem. The 
service holds instances of EntityManager. So if this bundle is updated I 
would expect it to close
all EntityManager instances. So the state would be lost. This is a very 
special case though and I dont think it would warant the Quiesce support 
all for itself.
After all updating aries jpa is rather seldom for a customer compared to 
updating their own bundles. So I think it should be ok to handle this 
case manually in a special way.

For updates of user bundles there should be no issue I think.

Btw. I am not yet sure what a refresh in OSGi actually does. Let us 
assume we refresh a bundle that provides a package that is imported by 
other bundles. Will these bundles also be refreshed then?
If not then I think  these bundles will not see the new package. So in 
case the package contains a service interface they will not see the new 
service. As this seems to work in practice (at least in karaf) I assume 
that in karaf the
client bundles are also refreshed. Is that correct?

Btw. this reminds me of this issue .
There we refresh a persistence unit bundle. After this the client bundle 
and the EntityManagerFactory saw different classes for the Entities.
I do not think this is Quiesce related though. If you have any ideas 
about that would be great as I do not seem to find any solution.

>> The doc mentions "threads started by this bundle".
>> If a bundle B calls a service from bundle A then the thread is not started
>> by bundle A. So it should be fine that this thread keeps running
>> even when the Activator.stop was called.
> Here's what the spec says for services (section 5.7, osgi core 6):  the
> behaviour of a a service object that becomes unregistered is undefined.
> Such service objects may continue to work properly or throw an exception at
> their discretion.  Imho, in a production environment, you don't really want
> to rely on an undefined behavior.  And if the service throws an exception,
> it's not a clean shutdown anymore.
I would interpret this part of the spec ("at their discretion") that the 
service implementor is free to either continue working or throw an 
So if he does not do anything special it should be fine.


Christian Schneider

Open Source Architect

View raw message