L'application se plante au niveau de la déclaration du bloc Synchronized

Bonjour à toutes et à tous,

J'ai une application web qui permet de faire pleins de trucs dont l'insertion de données en base.

Au niveau de l'implémentation de la méthode d'insertion, il y a un bloc synchronized qui contient des instructions "critiques" qui ne doivent être exécutées que par un seul thread à la fois.

Code:

---

1 2 3 4 5 6 7 8 9 10

public void inserer(Personne personne, Connection connexion){   //des instructions   synchronized (MaClasse.class) { //instructions critiques }   }

---

Je ne peux pas donner le code car c'est confidentiel.

Ma question est : normalement le bloc synchronized est censé gérer l'accès concurrent des threads, et donc être exécuté à la fois par un seul thread et faire attendre les autres. Le comportement que j'ai remarqué est que l'application se plante au niveau du mot synchronized, elle n'entre même pas dans le bloc, est-ce un comportement normal ? Quelles sont les raisons possibles pour un tel comportement ?

Merci

Hello,

ben non, ce n'est pas normal.
Mais pour en dire plus, il faudrait qu'on sache ce que veut dire "se planter", et comment diable t'y es-tu pris pour déterminer que ça arrive ici et pas ailleurs.

Citation:

---

Mais pour en dire plus, il faudrait qu'on sache ce que veut dire "se planter"

---

L'application est bloquée au niveau de ce bloc et on ne peut plus rien faire si on ne redemarre pas le serveur tomcat.

Citation:

---

comment diable t'y es-tu pris pour déterminer que ça arrive ici et pas ailleurs.

---

Je me suis servis des "logs", j'ai mis des logs partout dans la méthode d'insertion, notamment un juste avant le mot synchronized et un juste au début du bloc, comme suit :

Code:

---

1 2 3 4 5 6

log.info("insertion personne : début bloc synchronized"); synchronized (MaClasse.class){ log.info("insertion personne : début bloc synchronized"); //instructions }

---

En regardant ce qui est affiché dans la console, uniquement le 1er log est affiché. D'ailleurs l'affichage niveau console s'arrête au niveau de ce log là, voilà comment je sais qu'il n'entre pas dan le bloc et bloque vraiment au niveau de ce mot.

J'ai oublié de mentionner que , pour tester, j'ai remplacer le mot synchronized par un boolean :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public void inserer(Personne personne, Connection connexion){   //des instructions boolean access = false; if (access == false) { access = true; //instructions critiques access = false; }   }

---

L'application fait l'insertion sans aucun problème, mais je ne suis pas sûre dans ce cas est ce que l'insertion s'est faite correctement ou pas.

Salut,


S'il ne rentre pas dans le bloc synchronized il n'y a qu'une seule raison : un autre thread possède déjà ce lock.
Ce lock est-il utilisé autre-part ?


a++

Citation:

---

Envoyé par JQueen

J'ai oublié de mentionner que , pour tester, j'ai remplacer le mot synchronized par un boolean :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public void inserer(Personne personne, Connection connexion){   //des instructions boolean access = false; if (access == false) { access = true; //instructions critiques access = false; }   }

---

L'application fait l'insertion sans aucun problème, mais je ne suis pas sûre dans ce cas est ce que l'insertion s'est faite correctement ou pas.

---

accessest une variable locale, de ce fait ton bloc if sera toujours exécuté.
Est-ce que ta classe est static ? Je demande ça parce que tu poses un verrou sur MaClasse.class alors que tu aurais par exemple pu le faire sur this.
Est-ce que ton synchronized contient une autre méthode contenant un synchronized ?

Bonjour,

Citation:

---

S'il ne rentre pas dans le bloc synchronized il n'y a qu'une seule raison : un autre thread possède déjà ce lock.
Ce lock est-il utilisé autre-part ?

---

J'ai oublié de mentionner que ma classe MaClasse est un singleton :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

public class MaClasse{ ... /** instance. */ private static MaClasse instance = null;     public static MaClasse getInstance() { if (instance == null) { synchronized (MaClasse.class) { if (instance == null) { instance = new MaClasse (); } } } return instance; }

---

Ca aide ?

Citation:

---

Est-ce que ta classe est static ? Je demande ça parce que tu poses un verrou sur MaClasse.class alors que tu aurais par exemple pu le faire sur this.

---

Ma classe est un singleton. J'ai essayé d'utiliser le mot clé this à la place de la classe mais ça n'a rien changé.

Citation:

---

Est-ce que ton synchronized contient une autre méthode contenant un synchronized ?

---

Non, mon synchronized ne contient aucun autre bloc synchronized.

Merci.

EDIT: Ce message contient une erreur.

Message d'origine :

Ton bloc synchronized peut indirectement contenir un autre bloc synchronized si ce dernier est situé dans une méthode qu'il appelle.

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9

public void methode1(){ synchronized(MaClasse.class){} }   public void methode2(){ synchronized(MaClasse.class){ methode1(); } }

---

Exécuter methode2 provoquera un deadlock.

Citation:

---

Envoyé par Gugelhupf

Exécuter methode2 provoquera un deadlock.

---

non ce code là ne peux pas provoquer de deadlock, les deux blocs demandant le même verrou, tu ne peux pas avoir un thread dans methode1 et un autre en même temps dans methode2


Pour voir où sont les deadlock (car c'est vraissemblablement ça le problème), il faut fait un kill -3 de la jvm bloquée, elle donnera un output dans son stdout avec tous les threads et les potential deadlock.

Pour éviter un deadlock quand on joue avec des verrous, toujours acquérir les verrous dans le même ordre. Autrement dit, si tu as des bloc synchronized dans plusieurs instances / plusieurs classe, tu ne peux pas avoir un thread qui fais

instance 1 => instance 2
et un autre qui fait
instance 2 => instance 1

A notter qu'il n'est pas vraiment recommandé d'avoir besoin d'un synchonized pour manipuler tes données, t'as surement un plus gros problème de design si tu a besoin d'avoir recours à ça. Les connecteur type jdbc n'ont pas besoin de ça. :weird:

Salut,

Citation:

---

Ton bloc synchronized peut indirectement contenir un autre bloc synchronized si ce dernier est situé dans une méthode qu'il appelle.

---

Non c'est pas le cas.

Il y a peut etre un truc important que j'ai oublié de mentionner au tout début : ce cas de blocage se reproduit uniquement quand deux utilisateurs (ou plus) se connectent et lance une insertion instantanée.

Citation:

---

A notter qu'il n'est pas vraiment recommandé d'avoir besoin d'un synchonized pour manipuler tes données, t'as surement un plus gros problème de design si tu a besoin d'avoir recours à ça. Les connecteur type jdbc n'ont pas besoin de ça.

---

Tu veux dire, que quand on essaye d'insérer/modifier des données en base , notamment la même, c'est le SGBD qui va gérer la cohérence de données, et du coup pas besoin de gérer l'accès concurrent niveau java, c ça ?

C'est à ça que sert l'isolation des transactions au niveau du SGBD oui. Si tu active le niveau SERIALIZABLE, le sgbd te garantis que deux transaction simultanées auront un résultat identique à si les deux transactions avaient eu lieu l'une à la suite de l'autre, peux importe l'ordre. Si ce n'est pas possible de le garantir, l'une des transaction échouera.

Citation:

---

Envoyé par tchize_

non ce code là ne peux pas provoquer de deadlock, les deux blocs demandant le même verrou, tu ne peux pas avoir un thread dans methode1 et un autre en même temps dans methode2

---

En effet, j’admets ma bêtise, il aurait peut-être fallut que je donne un exemple avec 2 verrous, genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

// Thread n°1 synchronized(MaClasse1.class) { // 1. Verrou sur MaClasse1 synchronized(MaClasse2.class) { // 3. Impossible, MaClasse2 verrouillée   } }   // Thread n°2 synchronized(MaClasse2.class) { // 2. Verrou sur MaClasse2 synchronized(MaClasse1.class) {   } }

---

JQueen, je ne sais pas si ta méthode "inserer" contient des requêtes SQL, si c'est le cas pourquoi n'utilises-tu pas les transactions SQL ? (cf: si tu utilises du JDBC pure : con.setAutoCommit(true); et con.commit(); / con.rollback();, tuto Oracle ).

EDIT:
Erreur de copier/coller : ce n'est pas con.setAutoCommit(true);, mais con.setAutoCommit(false); qu'il faut effectuer pour démarrer la transaction.

Citation:

---

Envoyé par Gugelhupf

con.setAutoCommit(true);

---

Haaaaaaaa, brûlez le :massacre:

8-)

Salut,

Citation:

---

JQueen, je ne sais pas si ta méthode "inserer" contient des requêtes SQL, si c'est le cas pourquoi n'utilises-tu pas les transactions SQL ? (cf: si tu utilises du JDBC pure : con.setAutoCommit(true); et con.commit(); / con.rollback();, tuto Oracle ).

---

Mon application utilise le système de transactions, et je fais bien le con.setAutoCommit(true) au moment de l'ouverture de ma connexion.

Oui ma méthode inserer contient d'autres méthodes d'insertion qui eux exécutent des requêtes SQL en utilisant des PreparedStatement et des ResultSet.

Question : si j'ai mis en place tout ce système de gestion de transactions, et que mon objet manipulé (Personne par exemple) implemente l'interface Serializable, j'ai pas besoin de synchroniser sur des insertions, et je suis quasi sûre que mon SGBD va gérer la coherence (caractère ACID), c bien ça ?

JQueen, j'ai fait une erreur de copier/coller avec con.setAutoCommit(true);, c'est con.setAutoCommit(false); qu'il faut effectuer pour démarrer une transaction :

Code:

---

1 2 3 4 5

con.setAutoCommit(false); // Démarrer transaction   // Opérations INSERT-UPDATE-DELETE   con.commit(); // Valider la transaction

---

Voici ce qui se passe avec un con.setAutoCommit(true); (valeur par défaut lorsque tu récupères une connection) :

Code:

---

1 2 3 4 5 6 7 8 9

START TRANSACTION; -- Opération Java 1 INSERT ... COMMIT; START TRANSACTION; -- Opération Java 2 INSERT ... COMMIT; START TRANSACTION; -- Opération Java 3 INSERT ... COMMIT;

---

Avec autoCommit à false :

Code:

---

1 2 3 4 5

START TRANSACTION; -- con.setAutoCommit(false) est appelé INSERT ... -- Opération Java 1 INSERT ... -- Opération Java 2 INSERT ... -- Opération Java 3 COMMIT; -- si con.commit() est appelé

---

Oui un SGBDR gère les propriétés ACID si tu appliques les transactions comme indiqué dans l'exemple précédent (qui est du JDBC). Aussi si tu me parles d'une classe Personne qui implémente Serializable, tu utilises peut-être JPA/Hibernate pour stocker des objets Personne ? Dans ce cas il faudra regarder ton fichier persistence.xml mais de souvenir si ton projet est de type Java EE alors ton serveur d'application gère les transactions lui-même (en interne je ne sais pas comment JTA gère cela mais c'est comme ça).

Tu sais JQueen on sait bien que ton projet est confidentiel, mais on aurait certainement plus de facilité si tu nous montrais cette partie du code qui n'a pas l'air de relever du secret d'Etat.

PS: désolé _tchize là aussi je suis allé un peut vite mais je considère que c'est moins grave que tout à l'heure :aie:

bonjour,

Citation:

---

j'ai fait une erreur de copier/coller avec con.setAutoCommit(true);, c'est con.setAutoCommit(false); qu'il faut effectuer pour démarrer une transaction :

---

Oui oui je l'ai mis à false.

Citation:

---

Oui un SGBDR gère les propriétés ACID si tu appliques les transactions comme indiqué dans l'exemple précédent (qui est du JDBC). Aussi si tu me parles d'une classe Personne qui implémente Serializable, tu utilises peut-être JPA/Hibernate pour stocker des objets Personne ? Dans ce cas il faudra regarder ton fichier persistence.xml mais de souvenir si ton projet est de type Java EE alors ton serveur d'application gère les transactions lui-même (en interne je ne sais pas comment JTA gère cela mais c'est comme ça).

---

Oui j'utilise JDBC comme driver. Le stockage des objets est gérés par de simples requêtes SQL passées en paramètre des PreparedStatement. Pas d'utilisation d'Hibernate/JPA.

Et bien maintenant que ta méthode inserer() gère les transactions SQL, il n'est pas nécessaire que cette dernière contiennent un ou des blocs synchronized. Le problème ne peut plus venir de cette méthode vu que c'est ton SGBDR qui gère cette partie.

Attention j'insiste configurer aussi le niveau d'isolation des transactions. Tous les niveaux ne se valent pas et tous les sgbd ne mettent pas systématiquement le défaut au plus restrictif.

tchize_,

Précédemment t'avait dit :

Citation:

---

C'est à ça que sert l'isolation des transactions au niveau du SGBD oui. Si tu active le niveau SERIALIZABLE, le sgbd te garantis que deux transaction simultanées auront un résultat identique à si les deux transactions avaient eu lieu l'une à la suite de l'autre, peux importe l'ordre. Si ce n'est pas possible de le garantir, l'une des transaction échouera.

---

Quand tu dis "activer le niveau SERIALIZABLE, moi j'ai compris que les objets doivent implementer l'interface Serializable, ai-je bien compris ?

Citation:

---

Attention j'insiste configurer aussi le niveau d'isolation des transactions.

---

tu peux expliquer d'avantage STP.

Merci.

Dans les deux cas je parle de l'isolation de la transaction.

http://docs.oracle.com/javase/tutori...data_integrity

Suivant le niveau tu peux lire ce qu'une autre transaction n'a pas encore commité (dirty read),

Tu peux avoir des données différentes dans les même row d'un select fait deux fois dans la même transaction (non repeatable reads)

tx.begin
select * from tatable -> retourne id=1,name="toto"
select * from tatable -> retourne id=1,name="tata"
tx.commit

Tu peux avoir des row supplémentaire qui apparaissent

tx.begin
select * from tatable -> retourne id=1,name="toto"
select * from tatable -> retourne id=1,name="toto";id=2,name="titi"
tx.commit

Le TRANSACTION_SERIALIZABLE est le seul qui évite tous ces artefacts, mais c'est aussi le moins performant pour le SGBD en général. C'est défini via l'objet Connection en java.