Inline,
--- Luc Dewavrin <[EMAIL PROTECTED]> wrote: > Suite aux discussions sur les locks sur EJB, > je me posais une question concernant la concurrence > sur les EJB entit�s. Bon je vais essayer faire de mon mieux sachant que je n'ai jamais developpe de conteneur - donc il y aura certainement des betises dans ce que je vais dire ;-) > > Admettons que l'on ne soit pas dans un contexte > transactionnel, Pas bien deja surtout si tu accedes a une base de donnees. > si 2 ejb sessions stateless r�cup�rent le home stub > du JNDI et font > appel � la m�thode findbyPrimaryKey en passant la > m�me valeur, > que se passe-t-il ensuite lors de l'appel des > m�thodes sur le remote object? Chaque EJB SLSB aura son propre stub, i.e., deux instances differentes. > > - 2 instances d'EJB entit�s avec la m�me primary key > coexistent ? > - Les clients poss�dent tous les deux la m�me > r�f�rence vers le remote > object et le remote object est associ� � un unique > EJB. Les appels Je dirai aussi que chaque stub possede sa propre instance d'entity bean *conceptuellement* - car l'implementation est specifique a chaque conteneur. A mon avis plus facile a gerer (bien que - encore une fois je n'ai jamais essaye). Mais c'est facile "a voir", tu vais un println du hashcode de l'instance, et tu verras si elles sont differentes ou pas. un hashCode() sur l'instance de l'entity sera sans doute different pour les deux instances, mais dans le cas que tu decris, le hashCode() pour la cle primaire sera identique - vu que c'est la meme et que tu dois obligatoirement (conformement a la spec) implementer hashCode() et equals(). > aux m�thodes sont execut�es dans des threads > diff�rents? Oui - il y a un pool de threads, et chaque appel est fait dans un thread de ce pool. Note que deux appels successifs peuvent etre executes par la meme instance du thread: - thread 1 dispo - thread 2 dispo - exec-call-1(thread1, method1) - method-call-1 returns1 and thread1 goes back to pool - exec-call-2(thread1 (ou 2), method 2) - ... > > De plus, je me demandais comment un client indique > au conteneur qu'il n' a > plus besoin de > de travailler avec l'EJB entit� ( pour minimiser les > cas de concurrence ). > - Il affecte la valeur Null au remote stub et coupe > les communications > r�seaux du stub? > - Le garbage collector s'en occupe? Si chaque stub a sa propre instance d'entite, cela ne pose pas de probleme, sutout ne fait pas de remove() ;-) > > Enfin, bref, je suis preneur d'�claircissements sur > le sujet. Prendre ce que j'ai dis avec des pincettes. Thierry ===== Thierry Janaudy http://www.jyperion.com/ http://www.janaudy.com/ Accelerate EJB 2.0 development with EJBGen http://www.javaworld.com/javaworld/jw-02-2002/jw-0222-ejbgen.html __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
