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.

Quand il parlait du niveau serializable, je pense qu'il faisait référence aux "niveaux d'isolation" des transaction des SGBD, comme celui d'Oracle par exemple.
Oracle en propose 3 : Read committed (par défaut, pour qu'une autre session n'ait accès que ce qui a été commité), serializable, read-only*.
Je pense que tu devrais le laisser à son mode par défaut. N'hésite pas à lire la doc pour comprendre les différences, tu peux aussi lire celle de PostgreSQL pour la compréhension.

* : le standard SQL propose 4 niveaux d'isolation mais ce n'est pas le terme "read-only" qui est employé pour l'un des 3 existants dans Oracle il me semble.

EDIT : Zut il m'a devancé :aie:

Salut tchize_,

La méthode d'ouverture de connexion utilisée est la suivante :

Code:

---

1 2 3 4 5 6 7 8 9 10

public final Connection ouvrirConnexion() throws SQLException, NamingException { DataSource datasource = getDataSource(Constante.dataSource); Connection connexion = datasource.getConnection(); connexion.setAutoCommit(false); logger.info("Ouverture connexion : user : " + connexion); return connexion; }

---

Suite à ta remarque sur l'interface Connection, j'ai regardé la doc et j'ai trouvé qu'il existe une méthode Connection: setTransactionIsolation(int level) qui permet de spécifier le mode d'isolation de transactions.

Du coup, ma question est : est ce qu'il faut modifier le code comme suit pour garantir la bonne gestion de transactions concurrentes ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public final Connection ouvrirConnexion() throws SQLException, NamingException { DataSource datasource = getDataSource(Constante.dataSource); Connection connexion = datasource.getConnection(); connexion.setAutoCommit(false); connexion.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE); logger.info("Ouverture connexion : user : " + connexion); return connexion; }

---

Citation:

---

Gugelhupf, Je pense que tu devrais le laisser à son mode par défaut

---

C'est quoi le mode par défaut ? Est-il toujours le même ? Pourquoi a ton avis il faut garder ce mode ?


en regardant la doc : http://www.java2s.com/Code/JavaAPI/j...onintlevel.htm, je remarque qu'on fait ce qui suit :

Code:

---

1 2	connexion.setTransactionIsolation(connexion.getMetaData().getDefaultTransactionIsolation());

---

Je ne vois vraiment pas l'utilité de cette instruction :roll:

Citation:

---

Envoyé par JQueen

Du coup, ma question est : est ce qu'il faut modifier le code comme suit pour garantir la bonne gestion de transactions concurrentes ?

---

Ca dépend de tes besoins d'isolation, de ce que tu veux garantir dans ta db. Vu que tu utilise une datasource, pas besoin de code, en général il y a une option de configuration directement dans la définition de la datasource.

Citation:

---

Envoyé par JQueen

C'est quoi le mode par défaut ? Est-il toujours le même ? Pourquoi a ton avis il faut garder ce mode ?

---

Le mode par défaut dépends du SGBD.

Citation:

---

Envoyé par JQueen

Je ne vois vraiment pas l'utilité de cette instruction :roll:

---

Revenir à la valeur par défaut. Ca a peu d'intérêt pour un usage courant, le datasource est supposé faire ce boulot.

Bonjour,

Citation:

---

Vu que tu utilise une datasource, pas besoin de code, en général il y a une option de configuration directement dans la définition de la datasource.

---

Voilà comment je défini ma datasource dans mon fichier context.xml:

Code:

---

1 2 3 4 5

<Resource name="jdbc/dataSource" auth="Container" type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000" username="user" password="pwd" driverClassName="oracle.jdbc.driver.OracleDriver" url="jdbc:oracle:thin:@xxx.xx.xx.xx:xxx"/>

---

C'est à ce moment là que je configure le mode d'isolation de transaction ? comme suit :

Code:

---

1 2 3 4 5 6

<Resource name="jdbc/dataSource" auth="Container" type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000" username="user" password="pwd" driverClassName="oracle.jdbc.driver.OracleDriver" transaction-isolation="TRANSACTION_SERIALIZABLE" url="jdbc:oracle:thin:@xxx.xx.xx.xx:xxx"/>

---

Citation:

---

Envoyé par JQueen

C'est quoi le mode par défaut ? Est-il toujours le même ? Pourquoi a ton avis il faut garder ce mode ?

---

C'est l'un des 4 modes proposés par ton SGBD (ton SGBD peut en proposer moins). Celui d'Oracle (que tu sembles utiliser), ainsi que PostgreSQL, SQL Server et DB2 est Read Committed par défaut, celui de MySQL est Repeateable Read. Je garderais le mode par défaut pour une question de performance par rapport à mon besoin, donc soit je suis dans un environnement multi-utilisateur et ces utilisateurs ne modifient pas et ne font pas de lectures multiples sur un bloc de tuples durant leur transaction, soit je ne suis pas sur ce type d'environnement (ex: je fais la lecture de stats dans ma base que je considère comme un datawarehouse et il n'y a qu'un batch qui écrit de nuit).

L'inconvénient du mode Read Committed est que si tu as une première transaction qui modifie la table et une autre transaction qui lit plusieurs fois cette même table durant sa transaction (par exemple une première lecture avant et une seconde lecture après que l'autre transaction ait committé), tu peux te retrouver avec une incohérence (lectures des "mêmes" données qui ont étés modifiés). C'est donc à toi d'évaluer si cas arrive dans ton application. En ce qui me concerne 1 besoin = 1 requête SELECT, donc je ne pas censé rencontrer ce type de problème.

Si tu utilises <Resource> c'est que tu travailles dans un environnement où tu peux faire de l'injection de dépendance avec @Resource, autant en profiter ;)