Discussion :

[beegees]

Bonjour à tous,

J'ai ce message d'erreur :

la transaction a été bloquée sur les ressources verrou | objet générique pouvant être attendu par un autre processus et a été choisie comme victime

Sur ce code :

Code :

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

1
2
3
4
 
 $maj = $conn->prepare("UPDATE neuro_event SET position = :i WHERE id = :id");
 
$maj->execute(array(":i"=>$i, ":id"=>$maj_pos['id']));

Auriez-vous déjà rencontré ce message d'erreur ?

Sauriez-vous me dire comment le résoudre ?

Merci d'avance et bonne année.

beegees

[serge0934]

ton thread a été tué par un autre process, il peut y avoir beaucoup de possibilité.
retente le coup plusieurs fois, si cela se reproduit TOUT le temps tu as peut être un governorlimit trop faible (temps estimé par SQLserveur pour exécuter ta requête, si cela dépasse, il te kille...)

[SQLpro]

Il s'agit d'un cas de verrou mortel pour lequel SQL Server à choisi de tuer l'un des processus bloquants.

Les verrous mortels se produisent dans des transactions portant sur au moins deux tables (chaque processus devant mettre à jour au moins une table et lire ou écrire dans plusieurs autres tables).

Ils sont favorisés par :
1) une base non relationnelle (table fourre tout, à lire : http://blog.developpez.com/sqlpro/p1...ances-petites/)
2) des transactions trop conséquentes
3) des transactions côté client (dans l'application au lieu d'être dans des procédures stockées)
4) une logique transactionnelle inadaptée (par exemple commencer par des lectures et finir par des mises à jour)
5) l'utilisation de certains outils comme les ORM (à lire : http://sqlpro.developpez.com/cours/b...s-epaisses.pdf) ou les framework.

A +

[beegees]

Salut,

Merci à vous deux pour vos réponses.

Le problème ne semble plus se présenter.

Je reviens vers vous au cas où le problème réapparaît.

Encore merci pour les explications et meilleurs vœux.

beegees

[labilbe]

Dans ton cas, tu risques d'exécuter un nombre conséquent de mises à jour.
Ce qui veut dire que tu vas provoquer beaucoup d'allers et retours entre ton logiciel et le moteur de base de données (communication inter-process donc lent).
Une solution que je te propose serait de créer une requête UPDATE avec plusieurs UPDATE à l'intérieur (concaténation dans une chaîne).
Et pour éviter d'écrouler le serveur de BDD avec une requête trop complexe (n'ayant pas de contexte on peut imaginer que tu balances une chaîne avec 100 000 UPDATE), tu pourrais envoyer les UPDATE avec des lots de 100.
Cela réduirait les échanges et éviterait de faire trop de "marshalling" (transformation de code de ton logiciel vers SQL Server et re transformation du code de retour de SQL Server vers ton logiciel + communication inter-process).

[Chou-ette]

Bonjour

4) une logique transactionnelle inadaptée (par exemple commencer par des lectures et finir par des mises à jour)

Pour ma culture, en quoi est-ce inadapté ? auriez-vous un exemple ?

Merci

Edit: je n'avais pas vu le up monstrueux de 11 ans, mea culpa

[vanagreg]

a été choisie comme victime

Ils font dans le mélodrame chez SQL Server

[SQLpro]

Bonjour
Pour ma culture, en quoi est-ce inadapté ? auriez-vous un exemple ?

Merci

Edit: je n'avais pas vu le up monstrueux de 11 ans, mea culpa

Comme dit commencer par les lectures alors qu'il faudrait commencer par les mises à jour...

Autre template classique pour éviter certains verrous mortels, appeler les requête dans le même ordre...

A +