2010-11-06 9 views
3

J'ai un ressort CommonsPoolTargetSource défini pour un haricot. J'essaie de comprendre comment la mise en commun fonctionne, et quand un objet est renvoyé, le pool.Spring ObjectPooling & blocage des threads

Plus précisément, si j'ai un travailleur qui prend un objet mis en commun et invoque deux méthodes sur elle, comme suit:

public class MyWorker { 
    @Resource 
    Foo pooledFoo; 

    void doWork() 
    { 
     pooledFoo.doStepA(); 
     pooledFoo.doStepB(); 
    } 
} 

D'après ce que je peux voir dans les tests que j'ai couru, pooledFoo est pas en fait une instance de Foo, mais un proxy fourni par le pool. Le débit de la ci-dessus serait:

  • Invoking doStepA() sur foo récupère une valeur dans la piscine (bloquant le fil si l'on est pas disponible),
  • doStepA est exécuté sur le pooledFoo
  • lorsque doStepA terminé, pooledFoo instance est retourné à la piscine
  • contrôle revient à la méthode doWork et la méthode continue

Si cela est correct (pl aisez-vous me dire si ce n'est pas le cas), est-il juste de supposer que le pooledFoo retourné du pool lorsque doStepB() est invoqué, ne sera pas la même instance qui a été retournée pour doStepA()?

Répondre

3

Votre description du flux est correcte - l'objet sera emprunté au pool avant chaque invocation, et y sera renvoyé par la suite.

Toutefois, votre hypothèse suivante est erronée - il est tout à fait possible que stepB soit appelée par la même instance poolée que stepA. Cela dépend du «baratte» sur le pool - à quelle fréquence les objets sont-ils empruntés et retournés par des threads différents. Sous faible charge, le même objet peut être réutilisé.

Donc, il n'y a aucune garantie de quoi que ce soit ici. Avec les objets groupés, vous voulez généralement laisser l'objet groupé dans un état où il peut être utilisé par l'emprunteur suivant, que l'emprunteur ne soit pas le même thread.

+1

Merci - réponse très claire. –

Questions connexes