Avantage de SQL_TXN_SERIALIZABLE sur SQL_TXN_REPEATABLE_READ dans DB2 et C++

Question

Nous sommes confrontés à un problème dans notre application. Nous avons deux exemples de notre application de surveillance. Le comportement de l'application est la suivante:

Step 1. Monitor the ftp folder in a loop 
Step 2. If files are present, insert the file details to DB for the all files 
Step 3. Read the file details from the DB and process it 
Step 4. Once the file is selected from DB change the status to start processing so that no other process should process it. 

Nous avons ici deux processus de surveillance, deux instances du même programme (moniteur --instance 1 & & moniteur --instance 2)

ici à un moment donné, Les deux process monitor1 et monitor2 lisent les mêmes données de la base de données et du processus. Pour cette raison, le même fichier est traité deux fois. Cela est dû au retard à l'étape 3 et à l'étape 4. Monitor1 fait l'étape 3 et avant d'effectuer l'étape 4, monitor2 effectue également l'étape 3 de sorte qu'il ne savait pas que déjà monitor1 obtenait l'enregistrement.

Notre DB est db2 et nous utilisons le niveau d'isolation SQL_TXN_READ_UNCOMMITTED à l'étape 3. J'ai trouvé sur le site IBM que SQL_TXN_REPEATABLE_READ ou SQL_TXN_SERIALIZABLE sont des solutions pour cela, car cela empêchera la lecture de données corrompues.

Quelle est la meilleure option à utiliser dans notre situation. J'ai lu sur le net que SQL_TXN_SERIALIZABLE va ralentir l'accès à la base de données.

Si quelqu'un a rencontré ce problème en temps réel, pourriez-vous partager la solution.

Les pensées/suggestions sont les bienvenues.

Merci, Mathew Liju

Answer 1

Vous voulez probablement utiliser SQL_TXN_READ_COMMITTED, pas SQL_TXN_REPEATABLE_READ ou SQL_TXN_SERIALIZABLE, car il offre une meilleure concurrence que les deux autres méthodes.

Voir la documentation DB2 sur isolation levels, en gardant à l'esprit le mappage suivant:

CLI Name     DB2 Isolation Level 
    ------------------------ ------------------- 
    SQL_TXN_READ_UNCOMMITTED Uncommitted Read 
    SQL_TXN_READ_COMMITTED  Cursor Stability 
    SQL_TXN_REPEATABLE_READ  Read Stability 
    SQL_TXN_SERIALIZABLE  Repeatable Read 

Comme il semble que vous configurez un drapeau lorsque l'un des travailleurs commence à travailler sur un fichier, parlez-en à votre DBA pour savoir si la variable de registre DB2_EVALUNCOMMITTED a été activée, car cela peut également empêcher les deux threads d'attendre l'un de l'autre.