la Class Connection gere les transactions ...
 
De ce fait l'utilisateur qui lance une transaction à partir de son appli Java va bloquer les autres requetes, en ayant préalablement désactiver l'autocommit de la SGBD par un conn.setAutoCommit(false), sur cette même table pour les autres utilisateurs de cette meme appli tant que le 1er utilisateur n'a pas fait de conn.commit();
Et si un autre utilisateur lambda utilise ce programme dans un autre site et crée une nouvelle connexion il ne pourra executer sa requete sur la table concernée qu'apres le commit du 1er utilisateur  
 
C bien ça ?

Heu... j'oserais pas affirmer, mais à priori, un commit, c'est pas un verrou!

Ah ok ...
 
Et comment on peut "gérer" des verrous avec Java ?

Exact, l'autre utilisateur est bloqué jusqu'au commit ou rollback du premier utilisateur.

Où vois-tu ça ? Moi je pense que le setAutoCommit ne concerne que la transaction actuelle. Il est indépendant de toute autre connection pour la JVM. C'est le SGBD qui est à charge de gérer les requêtes concurrentes de plusieurs connections simultanées. Ça marche comme ça, non ?

 
bin oui
C'est au niveau du SGBD que la transaction se fait. Et setAutoCommit ne connecerne pas que la transaction actuelle mais la connection JDBC (ce qui revient plus ou moins au meme, tout dépend du code). En mettant à false tu dois faire un commit explicite. A true tu as un commit qui est envoyé à chaque opération traitée par la connection.

Je suis un peu largué.
Disons ceci
 
L'utilisateur T1 lance l'application Java, qui va lui meme lancer une requete dans la BD tout en ayant pris le soin de mettre setAutoCommit à false.
 
Au moment n+1, l'utilisateur T2, lance l'application sans mettre setAutoCommit à false (!), mais l'application veut faire une lecture de la table (la même que T1).
 
Est ce que T2 va être bloqué pour lire la table en attendant le commit de T1 ?
Ou est ce que T2 pourra lire la table sans les modifications de T1 ?
Ou Il pourra lire les modifs sans attendre le commit de T1 ?
 
Voilà en gros ce que je voudrais savoir  

bin ca n'a rien à voir avec Java. Tout dépend de ton SGBD! Tu lis les posts ou pas?
 
Tout dépend de ce que T1 aura fait. Si T1 n'a rien fait, T2 fais ce qu'il veut. Si T1 a modifié le record avec la clé 123, T2 ne pourra pas modifier 123 tant que T1 n'appelle pas commit
 
Ne mélange pas tout

Ok !
 
Donc si je veux avoir un accés exlusif pour un utilisateur sur une table (les autres utilisateurs n'ont pas le droit de lire (select), ni d'écrire(INSERT) dans la table, tant que cet utilisateur ne rend pas la main), c'est plus un problème à résoudre avec la SGBD et non un pb a résoudre avec la connection jdbc. C'est ça ?
 
Merci

Ah ok !  
J'ai trouvé :
 
5. Les niveaux d'isolation
Quel que soit le type de transaction locale ou globale, lors de transactions concurrentes, il se peut que les mêmes données puissent être lues, partagées et modifiées en même temps.
 
En regard du standard ANSI SQL92, il peut y avoir 3 types de problèmes relatifs aux transactions concurrentes et dans tous les cas les valeurs sont fausses du point de vue de la lecture :
 
Lecture sale ou " dirty read " : Une transaction lit des données contenant un changement non validé d'une autre transaction. Une partie des données peut se révéler fausse en fonction du commit ou du rollback de l'autre transaction.  
Lecture non répétable ou " nonrepeatable reads " : Une transaction lit une donnée, une seconde transaction change la même donnée et la première transaction relit la donnée et obtient une valeur différente. La donnée a changé et est incohérente sur la transaction.  
Lecture fantôme ou " phantom reads " : Dans une transaction on ré-exécute une requête, retournant un ensemble de données qui satisfont une condition de recherche. Un nouveau jeu de données apparaît entre les deux opération de lecture.  
Au niveau du système de données, il est possible de spécifier au ressource manager le niveau d'isolation transactionnelle pour éviter ce genre d'erreurs.
 
Ainsi un " isolation level " ou niveau d'isolation défini comment les transactions concurrentes sont isolées les unes des autres à des fins de lecture.
 
Les niveaux d'isolation suivants sont généralement supportés par les SGBDR ou les systèmes de données d'entreprise (EIS) et ainsi acceptés par les " ressource manager "
 
TRANSACTION_READ_UNCOMMITTED : La transaction peut lire des données non validées, c'est à dire des données qui ont été modifiées et non validées par des transactions concurrentes. Toutes les erreurs vues ci-dessus peuvent arriver.  
 Ce niveau est très dangereux dans les environnements stratégiques où des transactions simultanées mettent à jour des données partagées. Il est également inapproprié pour tous les calculs sensibles, comme les opérations de débit/crédit sur comptes bancaires qui doivent adopter un mode d'isolation plus strict.
 
 Ce niveau d'isolation reste approprié si vous savez à l'avance qu'une instance de votre composant ne fonctionne qu'en l'absence de toute autre transaction simultanée. Cependant, dans la plupart des contextes transactionnels, ce niveau d'isolation est insuffisant.
 
 Son principal avantage est la performance, comme le système transactionnel sous-jacent n'a pas besoin de verrouiller les données partagées.
 
TRANSACTION_READ_COMMITTED : Ce niveau d'isolation fait que l'on ne peut pas lire les changements non validés des transactions concurrentes.  
 Ce niveau est certainement plus robuste que le mode précédent. Vous ne pouvez plus lire les données écrites, et non validées, ce qui signifie par conséquent que toutes les données que vous lisez sont cohérentes.
 
 Ce mode est fréquemment utilisé pour les programmes qui effectuent des lectures en base pour constituer des rapports sur les valeurs des données.  
 
TRANSACTION_REPEATABLE_READ : Ce niveau d'isolation assure en plus que lire les données plusieurs fois retourneront les mêmes valeurs même si une autre transaction modifie ces données. Les lectures sont répétables.  
 Ce mode est utile lorsque l'on doit mettre à jour un ou plusieurs éléments de données d'une ressource, comme un ou plusieurs enregistrement d'une BDDR. Il est nécessaire de lire toutes les lignes et de les mettre à jour, en sachant qu'aucune n'est modifiée par d'autres transactions simultanées. Si on choisit de relire l'une de ces lignes ultérieurement au cours de la transaction, on a la certitude qu'elle contient les mêmes données qu'au début de la transaction.  
 
TRANSACTION_SERIALIZABLE : La transaction a les privilèges exclusifs en lecture/ecriture sur des données en les bloquant; les autres transactions ne peuvent ni lire ni écrire sur ces données. C'est le niveau d'isolation le plus contraignant empêchant également les " phantom reads ".  
 Ce mode doit être utilisé pour les systèmes stratégiques qui exigent une parfaite isolation transactionnelle. Il assure que les données lues ont été validées, que la lecture reste identique au fil du temps et que de mystérieuses données validées n'apparaissent pas dans la base en cours de traitement en raison de transactions simultanées.
 
 Ce niveau d'isolation doit être utilisé avec parcimonie, car il induit un coût certain. Si toutes les opérations sont réalisées dans ce mode, les performances de la base de données ont tendance à se dégrader très rapidement jusqu'à l'immobilisation éventuelle.  
 
 Les erreurs transactionnelles relatives aux 3 problèmes cités de lecture erronées pouvant s'avérer très difficiles à détecter, il est également bon d'utiliser ce mode pour s'en détacher complètement.  
 
Récapitulatif des différents niveaux d'isolation et de leurs effets respectifs  
Isolation Level Dirty Read Non Repeatable Read Phantom Read  
TRANSACTION_READ_UNCOMMITTED possible possible possible  
TRANSACTION_READ_COMMITTED aucune possible possible  
TRANSACTION_REPEATABLE_READ aucune aucune possible  
TRANSACTION_SERIALIZABLE aucune aucune aucune  
 
 
Ces niveaux d'isolations seront spécifiés aux RM via les outils permettant de gérer les conteneurs EJB, les données objet/relationnelles ou plus directement via les API JAVA.
 
Donc le TRANSACTION_SERIALIZABLE résoud mon pb ?

 
Ben, ça dépand si tu veux l'exclusivité au niveau de ton appli ou du SGBD global. Logique quoi !

Il faut bien différencier 2 choses:
 - si tu  veut le lock au niveau Java il faut mettre tes methodes synchronized (par exemple dans le cas de la creation d'une table temporaire)
 - si tu veut le lock au niveau SGBD, il faut transactionner tes requetes. Soit tu utilise les methodes setAutoCommit(), rollback(), commit() soit tu envoie directement les chaines 'begin transaction', 'rollback', 'commit' par un PreparedStatement. Suivant la config de ton SGBD le lock se fera par ligne, page ou table. Dans tout les cas les utilisateurs essayant de lire ou modifier une table transactionnée seront bloqués jusqu'a la fin de la transaction.

 
ma parole la situation n'est pas désespérée

 
C ironique ?
Parce que ça fait 3 h que j'essaie de comprendre  

 
Ok ! Merci pour l'info !

 
non t'as cherché tout seul et tu es tombé sur la bonne info, bravo

Bon je me suis cassé la tête pour rien, je viens de lire que MySql ne gère pas la conccurence ni les transactions ...

A part dans les versions 4.XXX.XXX et 5 qui sont en alpha ....

 
Edit: j'ai parlé trop vite la situation est effectivement plus complexe que je ne le pensais et j'ai appris qqch grace à toi, merci
 
voilà ce que j'ai trouvé pour ton prob de Mysql 3.X.X
 

 
http://www.educat.hu-berlin.de/doc [...] ansactions
 
question, pq ne pas utiliser mysql4?