Discussion :

[trotters213]

tout le monde,

Je viens chercher votre aide au sujet du mot-clé volatile.

Je fais des accès concurrents à une BD MySQL via un objet implémentant le patron Singleton me permettant de me connecter à cette base.

Ayant des problèmes de concurrences, j'utilise le mot-clé "volatile" qui me permet d'éviter des erreurs (lorsque, par exemple, je fais une grosse requête dans un client et que j'ouvre un autre client pour exécuter une autre requête).

J'aurais simplement voulu savoir s'il y avait des contre-indications sur l'utilisation de ce mot-clé, s'il était déprécié, si il ne fallait surtout pas l'utiliser avec des BD, ...

Merci d'avance pour votre aide.

[tchize_]

faudrait voir ton code, mais d'habitude ce n'est pas le mot clé volatile qu'on utilise pour çà. Volatile indique à la jvm et au compilateur de ne pas cacher le contenu de la variable dans les registres de la jvm. Pour les problème de multithreading on utilise la synchronisation.

[ndp]

faudrait voir ton code, mais d'habitude ce n'est pas le mot clé volatile qu'on utilise pour çà. Volatile indique à la jvm et au compilateur de ne pas cacher le contenu de la variable dans les registres de la jvm. Pour les problème de multithreading on utilise la synchronisation.

Dans certains cas l'utilisation du mot cle volatile est plus simple a mettre en place et plus lege que d'utiliser synchronized, donc dans ces cas la, il ne faut pas s'en priver.
Il faut l'avoir dans sa petite boite a outil, en sachant les differences avec synchronized (notamment par rapport a la section critique).

Exp d'utilisation: Positionnement/test d'un flag. Si un seul thread peut ecrire le flag, tous les autres etant en lecture dessus, alors la declaration en volatile de la variable est suffisante.

[tchize_]

comme si bien mentionné dans la faq de ce site, le mot clé volatile n'est pas nécessairement respecté par la jvm. De plus, à voir la question initiale (ok sans le code) j'ai l'impression que le posteur confond les roles de volatile et de section critique ou d'opération atomique...

[ndp]

comme si bien mentionné dans la faq de ce site, le mot clé volatile n'est pas nécessairement respecté par la jvm. De plus, à voir la question initiale (ok sans le code) j'ai l'impression que le posteur confond les roles de volatile et de section critique ou d'opération atomique...

hum.. le mot cle volatile? le model de memoire java? Il faudrait un peu plus de precisions dans la FAQ.

[tchize_]

y a une bonne explication (en anglais) sur les cas d'utilisation du volatile ici:
http://www.ibm.com/developerworks/ja...GX02&S_CMP=EDU

[ndp]

Dans l'article, il n'y a RIEN dedans qui parle d'un risque par rapport au fait que des jvms ne supportent pas le mot cle volatile.
C'est le point que je relevais dans ton precedent post.

• Aujourd'hui (ce n'etaits peut etre pas le cas avant),une jvm qui ne respecte pas la specification du language java sur cette partie est a oublier.
• Apres par rapport a l'utilisation de volatile,l'article de Brian Goetz est tres tres bon.

[trotters213]

Merci pour cette discussion (qui à l'air de partir en troll )

Voilà le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
private static volatile KCMySQLManagement.KPJNDIManagement FConnection = null;
 
public static synchronized Connection getInstance() throws KPException {
		try {
			if (FConnection == null) 
			{
				FConnection = new KPJNDIManagement();
				if (FConnection.getFConnection() == null) 
				{
					FConnection = null;
				}
			} 
			else 
			{
				if (!FConnection.isOpened()) 
				{
					FConnection.setFConnection(null);
					FConnection = null;
 
					FConnection = new KPJNDIManagement();
					if (FConnection.getFConnection() == null) 
					{
						FConnection = null;
					}
 
					KPGlobal.LOG0.error("--------------- MYSQL IS OUT");
				}
			}
		} catch (Exception e) {
			FConnection = null;
			KPException eKPException = new KPException(e.getMessage());
			eKPException.printMessage();
			throw eKPException;
		} finally {
			if (FConnection != null) {
				if (FConnection.getFConnection() != null) {
					return FConnection.getFConnection();
				}
			}
		}
		return null;
	}

Cela me crée le singleton de connexion.

Ce bout de code est la partie d'une application utilisant LCDS (pour ceux qui connaissent).

J'utilise le mot-clé volatile pour résoudre une erreur simple :
- je fais une longue série de requête (environ 6000) avec un client A
- je tente de me connecter à l'application avec un autre client B
Résultat : le client B ne se connecte pas tant que la série de requête n'a pas était réalisée.

Après différents tests effectués hier, je me suis rendu compte que ce mot-clé ne résolvait pas entièrement mon problème mais étant curieux je voudrais savoir pourquoi la déclaration de la variable en "volatile" m'a permis de surmonter ce problème.

Encore merci.

[millie]

Ce ne serait pas le mot synchronized sur tes méthodes static qui t'a permis de résoudre le problème ?

[trotters213]

Non la seule différence entre mon problème et ma "pseudo-solution" c'est "volatile".
Rien d'autre ni dans cette classe ni dans une autre.

[adiGuba]

Salut,


Quelques remarques :

• Déjà tu parles de singleton alors que ce n'est pas du tout le cas
• Les attributs static doivent être nommé en MAJUSCULE. Ici FConnection semble correspondre à un nom de classe ce qui rend le tout illisible...
• Les bloc finally ne devrait pas contenir de return ! Cela pourrait te cacher une exception...

Sinon : quel est l'objectif exacte de cette méthode getInstance() ?

a++

[tchize_]

je plusoie, le mot clé volatile, ici, ne sert absolument à rien à priori. On dirait que t'as mélangé deux patrons singletons pour java, le "traditionnel avec peu de performances":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public static synchronized X getInstance(){
    if (instance==null)
        instance = new X();
    return instance;
}

Et le double check avec volatile (java5 et plus uniquement)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 public class Singleton {
   private static volatile Singleton INSTANCE;
 
   // Protected constructor is sufficient to suppress unauthorized calls to the constructor
   protected Singleton() {}
 
   public static Singleton getInstance() {
      if (INSTANCE == null)
         synchronized(Singleton.class) {
           if (INSTANCE == null)
             INSTANCE = new Singleton();
         }
      }
      return INSTANCE;
   }
}

De plus, même avec ton bloc synchronizé, la valeur de retour de "FConnection.getFConnection()" est-elle toujours la même? Ou renvoie-t-elle à chaque fois une objet différent. Il faut voir si ces objets retournés sont multithread safe!

[ndp]

A vue de nez,je suis d'accord avec tchize_.
Le probleme peut aussi se situer ailleurs, les connections a la base de donnees peuvent etre un point de contention.

[trotters213]

OK je vais voir ce que je peux faire.

Pour répondre aux remarques en général :
- la syntaxe est induite par une convention de codage (toute pourri je le conçois et j'adhère )
- je reprends le code de quelqu'un qui démarre en Java donc soyez clément.

Merci pour votre aide.

[tchize_]

Non, moi c'est pas Clément, c'est David, sinon bon courage avec ta convention de codage

[®om]

je plusoie, le mot clé volatile, ici, ne sert absolument à rien à priori. On dirait que t'as mélangé deux patrons singletons pour java, le "traditionnel avec peu de performances":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public static synchronized X getInstance(){
    if (instance==null)
        instance = new X();
    return instance;
}

Et le double check avec volatile (java5 et plus uniquement)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 public class Singleton {
   private static volatile Singleton INSTANCE;
 
   // Protected constructor is sufficient to suppress unauthorized calls to the constructor
   protected Singleton() {}
 
   public static Singleton getInstance() {
      if (INSTANCE == null)
         synchronized(Singleton.class) {
           if (INSTANCE == null)
             INSTANCE = new Singleton();
         }
      }
      return INSTANCE;
   }
}

De plus, même avec ton bloc synchronizé, la valeur de retour de "FConnection.getFConnection()" est-elle toujours la même? Ou renvoie-t-elle à chaque fois une objet différent. Il faut voir si ces objets retournés sont multithread safe!

Juste pour dire, le deuxième est faux : http://christophej.developpez.com/tu...n/multithread/
Le plus simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public class MonSingleton {
    private static final MonSingleton INSTANCE = new Singleton();
    public static MonSingleton getInstance() {
        return INSTANCE;
    }
}

[tchize_]

Juste pour dire, le deuxième est faux : http://christophej.developpez.com/tu...n/multithread/

J'ai précisé "java 5 ou supérieur". C'est à dire des jvm dans lesqueles la portée du mot clé volatile a été étendue pour justement que les out of order write n'y soient pas autorisés

http://en.wikipedia.org/wiki/Singlet...ava_5_solution