Discussion :

[kodo]

Bonjour,
J'ai une classe singleton qui contient la méthode suivante, qui fait un simple Select :

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
public class UtilisateursManagerImpl implements UtilisateursManager {
	private EntityManagerFactory emf;
	private EntityManager entityManager;
 
	private static final Logger logger = LogManager.getLogger(UtilisateursManagerImpl.class.getSimpleName());
 
	public Object initialize() {
		if(emf!=null)
			entityManager = emf.createEntityManager();
		else
			logger.error("ERROR : emf NULL");
		return entityManager;
	}
 
	public synchronized boolean isValidUser(String login) throws Exception {
		List listResult;
		UserBean user = null;
		try {
			StringBuilder nativeSQL = new StringBuilder("");
			nativeSQL.append("select user.ID_UTILISATEUR from UTILISATEUR user where user.LOGIN_UTILISTEUR = :loginUser and user.EST_ACTIF = 1 ");
			Query queryNative = entityManager.createNativeQuery(nativeSQL.toString());
			queryNative.setParameter("loginUser", login);
			listResult = queryNative.getResultList();
			if (listResult != null && listResult.size() != 0)
				return true;
			return false;
		} catch (Exception de) {
			logger.error(de.getMessage());
			de.printStackTrace();
			entityManager.clear();
			throw new Exception(de.getMessage());
		} finally {
			entityManager.clear();
		}
	}
}

Ma question est ce que le fait de la rendre synchronisé est justifiable ?
Pour info, c'est spring qui gère la création de factory EMF et l'injection.

Merci.

[OButterlin]

Je ne vois pas d'information concernant le côté "Singleton" dans ce code et je ne sais pas comment Spring gère un Singleton.

Cependant, me basant sur les EJB, Singleton veut dire qu'il y a une instance unique dans la JVM, ça ne veut pas dire que la méthode ne peut pas être appelée de plusieurs endroits (plusieurs thread).

Du coup, ça pourrait être justifié de mettre la méthode en syncrhonized dans une classe Singleton (Avec les EJB, on a l'annotation @LOCK en plus qui permet de verrouiller).

Ceci dit, dans ce cas, je ne vois pas trop l'intérêt vu que la méthode ne fait qu'une lecture pour déterminer si l'utilisateur est valide et actif.

Donc, en résumé, pour moi et dans ce cas précis --> pas besoin

[thelvin]

A la rigueur si l'EntityManager était incapable de gérer plus d'une connexion à la fois...

Genre s'il maintenant sa connexion à la BDD en lieu et place d'en demander une à chaque fois (en principe venant d'un pool de connexion)

Mais bon, s'il fait ça les accès concurrents sont pas le seul problème, c'est déjà fragile en soi.

[kodo]

Je ne vois pas d'information concernant le côté "Singleton" dans ce code et je ne sais pas comment Spring gère un Singleton.

je voulais dire que j'ai un fichier de configuration bean.xml qui contient la ligne suivante :

Code :

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

<bean id="UtilisateursManager" class="com.ips.business.managers.impls.administration.UtilisateursManagerImpl"></bean>

Donc, en résumé, pour moi et dans ce cas précis --> pas besoin

On pourrait pas avoir ce cas, deux threads qui exécutent ce code, un est en train d'exécuter le select, l'autre est dans le block finally qui exécute la méthode clear, et donc exception pour le premier ?

[OButterlin]

Dans une programmation multi-thread, chaque thread a sa pile.
En l'occurrence, la connexion peut être la même mais les "statements" rattachés sont distincts, du coup, il n'y a pas de risque.
Dans tous les cas, comme les piles d'exécutions ne sont pas les mêmes, tout plantage dans un thread n'a pas d'incidence dans le second, sauf à partager des éléments (Ici, si la connexion est partagée, une fermeture de la connexion dans le thread 1 aurait un impact sur le thread2).

[kodo]

Merci pour les retours.

Ici nous avons une bean singleton avec un objet entityManager
Qui dit singleton, dit un seul objet dans la JVM. Donc tous les threads utilisent le même objet pour communiquer avec la base de données. Ce qui change est la connexion obtenue depuis le pool de connexion à chaque select. Donc je pense que nous avons toujours ce risque en cas d'accès concurrent. Non ?