Discussion :

[quincyj]

Bonjour,

Je travaille depuis quelques jours sur un projet java sur lequel la couche d'accès aux données est codée "à l'ancienne". A chaque demande client, on crée ouvre une transaction, on réalise le traitement, on ferme la transaction et on renvoie les données. La récupération d'une connexion se fait via une méthode d'un bean Spring dont voici 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
 
public Connection get_connexion(boolean readOnly) throws SQLException {
			Connection connection =dataSource.getConnection();
			try {
				connection.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
			} catch (SQLException e) {
				if(_log.isWarnEnabled()){
					_log.warn("Impossible de modifier le niveau de transaction de la connection");
				}
			}
			connection.setAutoCommit(autoCommit);
			connection.setReadOnly(readOnly);
 
			MySQLStoredProcedures.SP_INIT_VARS(connection);
			if(_log.isTraceEnabled()){
				_log.trace("Recuperation d'une nouvelle connexion.");
			}
			return connection;
	}

En soit, ça marche plutôt bien, donc pas envie de tout changer. Le gros problème est que si un client lance une transaction longue qui a readOnly=false, alors plus personne ne peux exécuter d'autres requêtes tant que la première transaction n'est pas terminée.

Comment puis-je régler ce problème svp ?

En vous remerciant d'avance,

[dinobogan]

C'est le principe de la transaction. La base de données garantie l'intégrité des données.
Les autres peuvent au mieux lire des données avec un niveau d'isolation bas (un dirty read) si la base de données le permet, mais ne pourront pas faire des modifications.

[quincyj]

Ok ça j'ai bien compris, mais le fait de mettre :

Code :

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

connection.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED );

devrait me permettre de lire des enregistrements alors que quelqu'un d'autre écrit, non ?

Sinon, quelles sont les bonnes pratiques pour éviter ce genre de problèmes ?
Faire plein de petits commit avec un save-point positionner au préalable ? Dans ce cas je ne risque pas de rollbacker également les données écrites par les transactions des autrs utilisateurs qui auront lieux pendant ce temps ?

Merci

[fr1man]

Quand tu dis plus personne ne peut exécuter de requête, c'est sur une table entière, plusieurs tables, juste une ligne modifiée par une autre transaction ?

[quincyj]

Au moins sur la table sur laquelle les inserts sont en cours

[fr1man]

C'est louche. Je ne vois pas pourquoi la table entière serait verrouillée, à moins de le faire explicitement: genre select * from taTable for update

[quincyj]

Je viens de constater quelque chose d'important.
Faire un utilisateur A fait une simple requête pendant la longue transaction de l'utilisateur B, ça fonctionne bien. En revanche, si A appel une procédure stockée alors ça ne fonctionne pas.

Si pendant l'exécution de la longue transaction (T1), A appel la requete contenu dans la procédure stocke, ça fonctionne.

Mon problème pourrait-il donc venir des déclarations de variables dans les procédures stockées ?

Code :

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

1
2
3
4
 
DECLARE ATT_EMAIL_ID INT;
 
SET ATT_EMAIL_ID = (select VALUE from param where `KEY` = 'EMAIL');

sachant que l'exécution de la requête select VALUE from param where `KEY` = 'EMAIL' ne pose pas de problème pendant l'exécution de T1.

Merci d'avance de votre aide. Il semble que le problème s'oriente clairement vers l'écriture des procédures stockées.

[dinobogan]

Selon la base utilisée, il peut y avoir des transactions implicites pour certains types de commandes.

[quincyj]

Peux-tu préciser un peu ta réponse stp ?

Après plusieurs tests, nous avons compris que ce qui entraine le deadlock exactement c'est le fait de faire :

SET <mon_param_out> = <requete>