Accès concurrents à la base de données

Je suis amener a créer une application qui permet une gestion des stock ...

Bien entendu, elle est multiUser donc je dois faire attention aux accès concurrents ...

En d'autre terme il faut absolument que lors d'une mise à jour d'une table il faut que l'utilisateur courrant soit seul dans cette section critique ...

Lorsque je fait un lookup pour avoir la référence à mon EJB, j'ai l'impression qu'il y a pluiseurs instance de cette classe qui tourne sur le serveur. Donc meme en mettant un synchronized, cela ne m'aidera pas ...

Alors ma question est la suivante : Faut-il absolument faire une classe intermédiaire bidule sur laquelle on fait le lookup pour avoir qu'une instance de l'objets qui fait la mise a jour (Singleton)

class truc{
MiseAJour maj= MiseAJour.getInstance();
}

truc etant appelé par les clients ...

Bonjour,

L'utilisation synchronized est interdit dans les EJB, cela resout ton problème :D (même si techniquement rien ne l'interdit).

Ton problème vient de la base de données, tu ne veux pas que deux utilisateurs accède à la même données simultanément.

Déjà, ce n'est pas la table entière qu'il faut protéger, mais un ou plusieurs enregistrements.

Il y a 2 approches pour résoudre le problème:
:arrow: L'approche optimisite
Tout va bien se passer :D (dans la majorité des cas) dans ton traitement, tu fais tes updates, mais en vérifiant qu'un autre utilisateur n'est pas passé dans le coin pour te modifier tes données.
Techniquement:
Au début tu récupères ton stocks
id=10
lib='ordi'
qt=101

Voici un moyen de vérifier:

Code:

---

update stock set qt=100 where id=10 and lib='ordi' and qt=101

---

Si l'update modifie 0 enregistrement, alors il y a un problème de modification et tu lances un exception.

L'avantage de cette méthode: Ne vérouille rien en base, pas de perte de vitesse. Il est possible avec cette méthode de faire de la vérification hors transaction, avec des actions utilisateurs longues

L'inconvénient: Quand le problème arrive, la transaction est annulée, dommage pour l'utilisateur...
C'est cette méthode qui est souvent utilisée.

:arrow: L'approche pessimiste
Je suis sur qu'un utilisateur va m'embéter :evil:
Donc je vérouille les enregistrements en lecture pour que les autres utilisateurs ne puisse pas y accéder:

Code:

---

select * from stock where id=10 for update

---

Donc après, je suis sur que mes données ne seront pas modifiées, je peux tranquillement faire:

Code:

---

update stock set qt=100 where id=10

---

L'avantage: Je suis sure du résultat.
L'inconvénient: Doit être limité à du traitement cours, sinon cela blocque les autres utilisateurs. Consomateurs de ressources BD. Ne peut pas être utilisée avec une interaction des utilisateurs. (hors transaction)

Les serveurs d'applications gèrent souvent ces techniques avec les EJB Entity (pas les BMP). Des flags permettent de précésier le mode de vérouillage souhaité.

Merci pour tout... J'espère juste que ces commandes marchent avec mysql :)

Citation:

---

Envoyé par cameleon2002

Merci pour tout... J'espère juste que ces commandes marchent avec mysql :)

---

8O Ourf,

MySQL n'est pas trop transactionel, n'isole pas les transactions quand au verouillage par ligne....

Donc regarde le mode optimisite, mais j'ai bien peur que MySQL fonctionne en "Dirty Read" (tu voix les données en cours des transactions des autres utilisateurs).

Je ne connais pas trop les bases freeware, mais il me semble que Postgress fonctionne bien mieux coté transactionel.

c'est clair postgreSQL gere un bout de transactionel et MySQL pas du tout.

si tu dois vraiment avoir des traitements transactionnels, penches toi de suite vers postgreSQL car passer de mySQL vers postgreSQL plus tard est problematique ( pas de subselect, ... ).


@+

OPk je vais voir sa ... Mais a priori je n'aurai pas de subselect, en tout cas pas dans l'immédiat. Sinon est ce que postgresql est gratos, meme en production car la philosophie de ma boite est la suivante : tu peux faire ce que tu veux tant que cela ne coute rien ... Bref c'est pas facil a trouvé ...

A ce que je vois y a pas de version pour windows pour l'instant ... Je vais donc devoir attendre jusqu'en 2004 :'(

Une base de prod sous Windows :!!!!!! :p

Sinon pour faire tourner PorstgreSQL sous Win, il faut passe par CigWin ( mais l'install est galère ).

Par contre sache que MySQL n'est pas gratos en prod, ce qui est le cas de postgreSQL.
Lis bien les licences.

Sinon il y a HSQL mais niveaux licence je en sasi pas ce que ca donne...

@+

Euh Mysql est gratuit en production tant que tu ne commercialises pas ton produit, d'après ce que j'ai vu :)


Pour l'environnement de production, je sais que windows n'est pas l'idéal, mais je n'ai que sa pour l'instant :'(

bah oui mais dans ce ca , c pa de la prod si c pas commercial !!! enfin c qu'une question de semantique tout ca..

Ils en sont ou MySQL des versions ?? elles est sortie celle qui doit prendre en compte les subselect ? ( je crois que c la 4 max ).


@+

Une question en passant:

Si on utilise un conteneur EJB (Genre Borland App Server ou JBoss) avec une base de donnees non transactionnelles, est-ce que la protection (pessimiste ou optimiste) marche quand meme?