多線程束和服務實例

假設我有3束甲，乙和B1。捆綁A是我的應用程序的起點。 Bundle B提供由A使用的服務的API。 Bundle B1是該服務的一個實現。多線程束和服務實例

基本上，捆綁A有一套記錄，它一個接一個地處理。沒有處理記錄的命令。

我想通過同時處理記錄的子集來提高我的應用程序的性能。

我想到了兩種不同的方式：捆綁包A的多個實例和捆綁有多個線程的捆綁包A.

AFAIK，不可能在OSGi容器中添加同一捆綁包的多個實例（即相同的OSGi身份）。

關於第二種可能性，由包A創建的每個線程都有自己的標識。而由B1導出的服務需要知道使用它的線程的身份。因此，我認爲ServiceFactoy適合在這裏。但是，我已經讀過，一旦一個服務實例被一個包獲得，它就會被緩存。因此，所有的線程都會得到相同的服務實例。

我對不對？如果是，那麼實施這種模式的「正確方法」是什麼？隨意爲我提出一個更加OSGi友好的完全不同的方法。

謝謝，邁克爾 -

編輯：

另一種可能性是修改服務接口，以允許該服務的消費者，他們的身份傳遞給服務。該服務將變成「無狀態」，並且不需要使用ServiceFactory。然而，身份所要求的事實是實現細節（即僅需要該特定實現），因此對於未來的實現，添加到接口的參數將不被使用。這就是爲什麼我不喜歡接觸界面的原因。

來源

2014-02-06 Mickael Marrache

你是什麼意思的「線程的身份」？你使用技術？如果我是你，我會嘗試在新線程中傳遞相同的標識（猜測設置線程局部變量）。 –

我的意思是在線程創建期間設置了一些硬編碼標識集。該身份將用於配置服務實例。使用相同的標識不會幫助我，因爲返回的服務實例應該在每個線程中進行不同的配置。 –

您可能會對此RFC感興趣：https：//github.com/osgi/design/blob/master/rfcs/rfc0195/rfc-0195-ServiceScopes.pdf但是，我認爲您仍應該考慮重構它可以處理來自多個線程的請求。例如：將自定義工廠註冊爲服務，而不是註冊服務本身。在這種情況下，實例化將在您的手中，您可以通過工廠方法的參數傳遞身份信息。 –

OSGi中的「正確方式」是提供無狀態的服務。

正如您已經發現的那樣，ServiceFactory概念對您沒有幫助，它只區分調用bundle而不是線程，上下文或其他任何可以作爲狀態容器的東西。

如果你的服務必須跟蹤狀態，最好的方法是做出明確的並提供某種參數來通過狀態。 Balazs提到的RFC是未來的另一種選擇（只要它符合規範）。

來源

2014-02-06 14:51:06

多線程束和服務實例

回答

相關問題