Update concurrents sur une même table

Bonjour à tous,

Mon application se bloque aléatoirement lorsque je fais un update sur ma base de données. Cette application fonctionne dans un environnement Glassfish 3.01, base de données MS SQL Server 2005 (driver sqljdbc4).

Cet update se fait dans un BMT de la manière suivante :

Code:

---

1 2 3 4 5

utx.begin(); entity.setEnabled(false); entity.setStatus(1); utx.commit();

---

Il arrive que l'application se bloque lors du commit (au bout de quelques milliers d'update).

A noter que l'application multi-thread et soumise à une grosse charge de travail : les accès concurrents à la base sont largement possibles, mais jamais sur la même ligne (chaque ligne n'est traitée qu'une fois). Y'a t il quelque chose à paramétrer pour que mon commit puisse se faire correctement ?

Merci !

Bonjour,

Il manque une partie du code ?
Des exceptions, dans les logs ?
y a t'il un try .... catch ?

tx.begin est une transaction, donc ... cela devrait fonctionner, peut être
un time out ?

sinon, si tous utilisent la même table pour un update @singleton + les @...
qui vont bien pour gérer la partie transactionnelle .

olivier

Merci olivier pour ta réponse,

Il manque en effet une partie de code et des explications.

Je suis dans un singleton et je travaille dans un try catch. Ma transaction fonctionne déjà avec un time out qui ne semble avoir aucun effet :

Code:

---

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

@Singleton @LocalBean public class ResultHandler { [...] try { synchronized(utx) // est ce raisonnable ? { utx.setTransactionTimeout(15); utx.begin(); entity.setEnabled(false); entity.setStatus(1); utx.commit(); } } catch(Exception e) { Logger.getLogger(ResultHandler.class.getName()).log(Level.INFO, "Erreur transaction [{0}]", e.getMessage()); } [...] }

---

Je n'ai aucune exception dans les logs, seulement une stacktrace récupérée avec jvisualvm : le thread bloqué attend dans la méthode read du SocketInputStream utilisé par le driver JDBC (le serveur SQL ne répond pas : problème de lock ?)

Qu'entend tu par "+ les @... qui vont bien" ?

BOnjour,

Il faut peut être utiliser

Code:

---

1 2 3 4

@Singleton @ConcurrencyManagement(ConcurrencyManagementType.Bean) public class ...

---

C'est dans la doc de glassfish, quand tu gères avec un méthode synchronized.

ils nomment cela un BMC, Bean managed Conncurrency

olivier

Ok je vais déjà essayer cela : je n'avais pas encore rencontré cette annotation.

J'ai oublié d'évoquer le fait que mon bean avait l'annotation @TransactionManagement(TransactionManagementType.BEAN). Je le sous-entendais néanmoins par le BMT.