Многопоточные пакеты и сервисные экземпляры
Предположим, у меня есть 3 пучка A, B и B1. Пакет А является отправной точкой моего приложения. Пакет B предоставляет API сервиса, используемого A. Bundle B1 является реализацией сервиса.
В основном, пакет A имеет набор записей, которые он обрабатывает одну за другой. Нет заказа на обработку записей.
Я хотел бы улучшить производительность своего приложения, обрабатывая подмножества записей одновременно.
Я думал о двух разных способах: множественные экземпляры комплекта A и комплекта A с несколькими потоками.
AFAIK, невозможно добавить несколько экземпляров одного и того же пакета (т. Е. Идентичные идентификаторы OSGi) в контейнер OSGi.
Что касается второй возможности, каждый поток, созданный пакетом A, будет иметь свою собственную идентификацию. И сервис, экспортируемый B1, должен знать идентификатор потока, который его использует. Таким образом, я подумал ServiceFactoy подошло бы здесь. Тем не менее, я прочитал, что как только экземпляр службы получен пакетом, он кэшируется. Следовательно, все потоки получат один и тот же экземпляр службы.
Я прав? Если да, то каков "правильный путь" для реализации этой модели? Не стесняйтесь предлагать мне совершенно другой подход, более дружественный OSGi.
Спасибо, Микаэль
РЕДАКТИРОВАТЬ:
Другой возможностью было бы изменить интерфейс Сервиса, чтобы позволить потребителям Сервиса передавать свои идентификационные данные Сервису. Служба затем станет "не имеющей состояния", и использование ServiceFactory не потребуется. Однако тот факт, что идентификационная информация требуется, является подробностью реализации (то есть требуется только для этой конкретной реализации), поэтому для будущих реализаций параметры, добавленные в интерфейс, не будут использоваться. Вот почему я предпочитаю не трогать интерфейс.
1 ответ
"Правильный путь" в OSGi - предоставлять услугу без сохранения состояния.
Как вы уже обнаружили, концепция ServiceFactory вам не помогает, она только различает вызов пакетов, а не потоков, контекстов или чего-либо еще, что может быть контейнером для состояния.
Если ваша служба должна отслеживать состояние, лучший способ - сделать это явным и предоставить какой-то параметр для передачи состояния. RFC, который упоминает Balazs, является еще одним вариантом в будущем (при условии, что он включен в спецификацию).