多线程捆绑和服务实例 [英] Multithreaded bundle and service instances

问题描述

假设我有3个捆绑包 A ， B 和 B1 .捆绑 A 是我的应用程序的起点.捆绑包 B 提供了 A 使用的服务的API.捆绑包 B1 是该服务的实现.

Assume I have 3 bundles A, B and B1. Bundle A is the starting point of my application. Bundle B provides the API of the service used by A. Bundle B1 is an implementation of the service.

基本上，包 A 具有一组记录，它们彼此接连处理.没有处理记录的顺序.

Basically, bundle A has a set of records that it processes one after the other. There is no order for processing the records.

我想通过同时处理记录的子集来提高应用程序的性能.

I would like to improve performance of my application by processing subsets of records concurrently.

我考虑了两种不同的方式:bundle A的多个实例和具有多个线程的bundle A.

I thought about two different ways: multiple instances of bundle A and, bundle A with multiple threads.

AFAIK，不可能在OSGi容器中添加同一包(即相同的OSGi身份)的多个实例.

AFAIK, it is not possible to add multiple instances of the same bundle (i.e. same OSGi identity) in an OSGi container.

关于第二种可能性，捆绑软件 A 创建的每个线程将具有其自己的身份.并且 B1 导出的服务需要知道使用它的线程的身份.因此，我认为ServiceFactoy将适合此处.但是，我读过，一旦捆绑包获得了服务实例，就将其缓存.因此，所有线程都将获得相同的服务实例.

Regarding the second possibility, each thread created by bundle A would have its own identity. And the service exported by B1 needs to know the identity of the thread that uses it. Thus, I thought a ServiceFactoy would fit here. However, I've read that once a service instance is obtained by a bundle, it is cached. Therefore, all the threads would get the same service instance.

我是对的吗?如果是，实施此模型的正确方法"是什么?随时向我提出一种与OSGi更加友好的完全不同的方法.

Am I right? If yes, what is the "right way" to implement this model? Feel free to propose me a completely different approach that is more OSGi friendly.

谢谢， 米凯尔(Mickael)

Thanks, Mickael

另一种可能性是修改服务接口，以允许服务的使用者将其身份传递给服务.然后，该服务将变为无状态"，并且不需要使用ServiceFactory.但是，需要标识这一事实是实现细节(即仅对于此特定实现才需要)，因此对于将来的实现，将不使用添加到接口的参数.这就是为什么我不想触摸界面的原因.

Another possibility would be to modify the Service interface to allow the service's consumers to pass their identity to the Service. The Service would then become "stateless" and the use of ServiceFactory would not be required. However, the fact the identity is required is an implementation detail (i.e. it is required only for this specific implementation), therefore for future implementations, the parameters added to the interface would not be used. This is why I prefer not to touch the interface.

推荐答案

OSGi中的正确方法"是提供无状态服务.

The "right way" in OSGi is to provide a service that is stateless.

您已经发现，ServiceFactory概念无济于事，它仅在调用包，线程，上下文或任何其他可以作为状态容器的对象之间进行区分.

As you have already discovered, the ServiceFactory concept does not help you, it only differentiates between invoking bundles, not threads, contexts or anything else that can be a container for state.

如果您的服务必须跟踪状态，则最好的方法是使其明确，并提供某种参数来传递状态. Balazs提到的RFC是将来的另一种选择(前提是它可以纳入规范中).

If your service must keep track of state, the best way is to make that explicit and provide some kind of parameter to pass the state. The RFC that Balazs mentions is another option in the future (provided it makes it into the specification).

这篇关于多线程捆绑和服务实例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！