Le verrou mortel est en cours de mise à jour de la même base de données dans plusieurs sessions de connexion

Nous avons implémenté une application basée sur le socket client pour traiter plusieurs demandes de panier. Chaque jour, nous recevons des milliers de demandes de panier. Pour cela, nous avons implémenté une architecture multi-thread pour traiter les demandes simultanément. Nous utilisons Oracle Connection Pool pour les opérations de base de données et nous définissons une valeur optimale pour la taille du pool de connexions. Conformément à notre processus métier, nous disposons d'une table de base de données principale et nous devons mettre à jour le même ensemble de lignes par plusieurs threads en utilisant plusieurs sessions de connexion simultanément. Maintenant, obtenir des problèmes de verrouillage mort à cause de plusieurs threads va essayer de mettre à jour les données sur les mêmes lignes en utilisant plusieurs sessions de connexion en même temps et nous sommes également d'autres violations de clé primaire sur les tables. Parfois, la base de données est également verrouillée en insérant simultanément les mêmes données dans plusieurs sessions de connexion.Le verrou mortel est en cours de mise à jour de la même base de données dans plusieurs sessions de connexion

S'il vous plaît me suggérer une bonne approche pour gérer les problèmes ci-dessus immédiatement.

Source

2010-10-01 Kiran Kumar

Si vous pouviez nous montrer du code, cela aiderait ... En général, si vous devez mettre à jour les mêmes données, ces opérations seront sérialisées ... – Guillaume

Il existe quelques solutions générales différentes pour écrire du code multithread qui ne rencontre pas d'interblocages. Le plus simple est de s'assurer que vous verrouillez toujours les ressources dans le même ordre. Un blocage se produit lorsqu'une session détient un verrou sur A et veut un verrou sur B alors qu'une autre session maintient un verrou sur B et veut un verrou sur A. Si vous vous assurez que votre code verrouille toujours A avant B (ou B avant A), vous pouvez être assuré que vous ne serez pas dans une impasse. En ce qui concerne les violations de clé primaire, utilisez-vous autre chose qu'une séquence Oracle pour générer vos clés primaires? Si oui, c'est presque certainement le problème. Les séquences Oracle sont explicitement conçues pour fournir des clés primaires uniques dans le cas où vous avez plusieurs sessions faisant des insertions simultanées.

Source

2010-10-01 09:11:17

Merci Cave for Prompt response. Nous avons implémenté un mécanisme d'attente et de notification sur un code spécifique pour chaque thread. Par cette approche, les serrures mortes ne se produisent pas. Mais l'inconvénient de cette approche est que si n'importe quel thread prend un temps significatif qui aura un impact sur d'autres threads car ce processus sera un mode sériel. Si nous avons écrit toutes les opérations de base de données dans la procédure stockée, alors que tous les threads accédant à cette procédure de stockage, est-il placer un verrou pour chaque thread? –

Nous obtenons des violations primaires dans la table enfant pas dans la table parent. Ce problème, nous allons prendre soin en exécutant à nouveau le processus. Le problème principal est la base de données se verrouillé lorsque chaque thread tente d'insérer ou de mettre à jour la table de données enfant dans chaque session de connexion différente simultanément. Même parfois, le système était également pendu. Nous ajoutons toutes les instructions insert ou update sql dans Batch. En fait, dans ce scénario, nous devrions avoir un verrou mortel, mais la base de données ne prévoit aucune exception. Pour ce processus, nous n'avons pas implémenté ci-dessus wait et notifier le mécanisme. –

Le verrou mortel est en cours de mise à jour de la même base de données dans plusieurs sessions de connexion

Répondre

Questions connexes