Salut, En general, tu resouds ce probleme par l'utilisation du pattern "version number" (Telecharge http://www.theserverside.com/books/EJBDesignPatterns/index.jsp, puis va page 70).
Le probleme etant qu'en general on ne "demarre" pas de transaction a partir du client pour la lecture de donnees et locker ces dernieres. Tout depend de ce que tu veux faire, je vois ici 3 possibilites: 1) Recuperer l'adresse par U1 et "empecher" sa lecture par tout Ui, i!= 1 - puis la modifier/sauvegarder. 2) Recuperer l'adresse par U1 et permettre sa lecture par tout autre Ui, i!= 1, mais sans permettre de modifications pour Ui, i!= 1 3) Recuperer l'adresse par tout Uj, chacun ayant la possibilite de modifier l'adresse et de la sauvegarder. Ces points peuvent se resoudre par l'utilisation de patterns, et ce que l'on appelle Isolation Level. Si tu lis la spec EJB 2.0, section 17.3.2, tu verras que la specification des "niveaux d'isolation" en dehors de la spec EJB, donc il faut que tu te rapproches de la documentation du serveur J2EE que tu utilises; ainsi que la base de donnees que tu utilises (toutes ne supportent pas les Isolation Levels [IL dans la suite de l'email] que tu voudrais utiliser). En plus de cela, il faut tout de meme definir ces IL. Les IL permettent de definir la facon dont les transactions sont isolees les unes des autres lorsque tu fais une lecture. La plus restrictive des IL est TRANSACTION_SERIALIZABLE. Tu peux - demarrer un transaction - lire/modifier - commiter cette TX et pendant ce temps la les autres TX n'auront pas le droit d'acceder aux donnees. TRES couteux en terme de performance. Si tu utilises WLS 6.1 (et 7 je suppose) avec Oracle (je sais, je suis restrictif ;-)), tu peux utiliser TRANSACTION_READ_COMMITTED_FOR_UPDATE qui te permet de poser un verrou sur les donnees auxquelles tu accedes avec un SELECT jusqu'au prochain COMMIT ou ROLLBACK. Pour compliquer la situation, tu peux avoir des locking au niveau du conteneur EJB, ainsi qu'au niveau de la base de donnees. Dans le premier cas, tu peux interdire l'acces a une instance d'un entity bean par d'autres clients qui voudraient utiliser cette instance... il n'y a quasiment pas de ejbLoad dans ce cas. Dans le deuxieme cas le mecanisme est delegue a la base de donnees. Plus ejbLoad, les access concurrentiels sont plus performants. Je suis perdu la, au fait c'etait quoi la question? Ah oui.... dans ton cas, il semblerait que tu ais une interface utilisateur, et il serait mal venu de poser un lock sur des donnees si par example ton utilisateur mets 2 heures avant de faire une update! Le plus simple, a mon avis, et l'utilisation du "version pattern" dont j'ai parle plus haut. A toi de gerer l'exception et de la remonter au niveau de ton utilisateur pour lui dire par example, "L'adresse a ete changee par un autre utilisateur, voulez-vous: a) lire la nouvelle adresse, b) confirmer vos changements, c) help" Cela revient a implementer une strategy "optimiste". Je crois que WLS 7 supporte cela - je lis la doc - mais peut-etre utilises-tu un autre app server? (jBoss, Websphere, Pramati, ...) - Si tel est le cas, rapproche toi de leur documentation specifique. Thierry --- Jean-Baptiste BRIAUD <[EMAIL PROTECTED]> wrote: > Bonjour a tous, > > Je me pose une question existentielle sur les lock > avec les EJB. > Comment est gere le scenario suivant : > 2 utilisateur U1 et U2 manipule une "fiche" a > l'�cran, > fiche representant une instance de l'entity > PERSONNE. > > U1 modifie l'adresse de la personne P1 et sauve. > Pendant ce temps la, U2 qui lisait la fiche de P1 > (avec l'ancienne adresse) > la modifie a son tour mais differemment et sauve. > => La modif de U1 est perdue. > > Il existe des variations de se scenario. > > Comment cela est-il gere par J2EE + EJB ? > Lock optimistes ? Lock pessimistes ? Pas de lock (a > faire sois m�me) ? > ____________________________________________________ > Jean-Baptiste BRIAUD Sysdeo > > Software engineer http://www.sysdeo.com > > ===== 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
