[INTERBASE] Arrêt des transactions

[Vulcanos]

Bonjour à tous,

Sous Interbase, quels sont les inconvénients à ne pas fermer systématiquement les transactions associées aux requêtes ? Les temps de réponse sont-ils augmentés ?

Merci d'avance pour votre réponse.

[Barbibulle]

Celà dépend du type de transaction, Laisser ouverte une snapshot plusieures heures alors qu'il y a beaucoup d'autre transactions qui font des MAJ ou suppression, ca mange des resources et ralentis forcément les requetes.

[Vulcanos]

Dans le cas qui m'intéresse, il s'agit de transactions portant sur des requêtes "légères".

Merci de votre réponse.

[Barbibulle]

Des mises à jours ? Et quel type de transaction ?

Difficile de répondre comme ca, il n'y pas de réponse générale, dans le cas normal d'utilisation ca ne pose pas de probleme.

Mais bon que veux dire "cas normal d'utilisation" ?

Je ne connais pas vos contraintes, vos volumes, le nombre de connexions simultanée etc. Donc difficile de dire.

Ce qu'il faut savoir c'est qu'une transaction d'ouverte oblige le serveur à la gérer et quand une mis à jour est faite par exemple, le serveur va inspecter toutes les transactions en cours pour détecter un éventuel conflit. Donc oui ca mage des resources mais bon si vous suivez les règles de bon sens vous n'aurez pas de PB.
Les transactions de MAJ doivent êtres les plus courtes possible (ne pas laisser des Updates non commités pendant des dixaines de minutes) mais bon avant d'avoir un PB de performance sur ce genre de probleme vous aurez des problemes de conflits de MAJ probablement.

[Vulcanos]

J'avais suivi le débat (il y a qques semaines) sur ce forum concernant la façon de poser les transactions. J'y ai trouvé bcp de choses intéressantes et surtout, ça m'a permis de repenser le sujet.

Pour celà, j'ai repris mon projet préféré afin de voir comment j'avais géré mes transactions. Je pense qu'on peut modéliser 80% au moins des situations. On pourrait faire une typologie qui ressemblerait à :

- Ecran de consultation simple,
- Ecran de mise à jour,
- traitement "batch" de lectures massives (statistiques systématiques),
- traitement "batch" de lectures massives avec lectures préalables (stats glissantes),
- traitement "batch" d'insertions massives,
etc...

Par exemple, dans le cas d'1 écran de mise à jour, il me semble qu'ont devrait avoir idéalement (pour une appli "fortement" concurrentiel) :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
1- Lecture des infos
Ouverture transaction 1 READ Commited
Positionnement Groupe Info 1 (ex : Nom client, N° de client)
CommitRetaining transaction 1
Positionnement Groupe Info 2 (ex : Factures du client)
Commit Retaining transaction 1
...
Commit transaction 1  
 
2- Mise à jour
Positionnement Groupe Info 1
CommitRetaining Transaction 1
Comparer Froupe Info 1 avec le précédent
Si Ok, mise à jour
Commit Retaining transaction 1
...
Commit transaction 1 
Fermer transaction 1

J'avais déjà expérimenté cette solution (qui ne m'appartient pas) sur mainframe. C'est lourd, mais trés efficace.

Ca semble nous éloigner de ma question initiale, mais elle était le préalable à une réflexion plus vaste. Je ne sais pas ce que vous en pensez...

[Barbibulle]

Je ne suis pas certain d'avoir tout compris mais j'ai l'impression que vous vous compliquez la vie.

Personnellement j'ai trois approches :
1- Je laisse l'utilisateur passer du temps à faire une MAJ quitte à ce quelle soit refusé lors de son application parce qu'un autre a fait une mise à jours avant lui.
Dans ce cas j'utilise une simple ReadCommited pour la lecture et dans la même transaction j'applique la MAJ.
Si entre la lecture et la MAJ une autre transaction a modifié mon enregistrement, je vais avoir une exception lors de mon update. Et là deux options : Abandonné les MAJ et rafraichir l'enregistrement pour avoir la dernière version. Ou mémoriser les modifications, rafraichir l'enregistrement et comparer les différences, s'il y en a, les signaler à l'utilisateur.(La plupart du temps cette deuxième solution est innutile car en général les gens travaillent sur des dossiers différents et de plus en plus un client est suivit par une seule personne et donc les données ne sont pas modifiés par plusieurs personnes à la fois.)

Soit
2- Le dernier qui met a jour à raison (quitte à ce que ce dernier ait fait une MAJ sans avoir vu ce que l'autre avait fait comme MAJ)
Dans ce cas pour l'affichage j'utilise une transaction readcommited ou autre et pour effectuer les MAJ j'ouvre une autre transaction, je fais l'update puis commit immédiatement après.

Soit
3- Utilisation du cache Update (les MAJ ne sont faites que localement dans un cache et appliqués à la demande dans une seule transaction).
Celà réduit fortement le trafic réseau et le nombre de transaction simultanée (car beaucoup plus courtes). Mais le PB c'est que ce n'est pas raisonnablement enviageable si vos données sont très volatiles.

[Vulcanos]

En fait, ma solution pour un écran de mise à jour correspond à votre première solution. Trop lourde dans beaucoup de cas, je suis d'accord.

OK pour la solution 3 (Cache)

Mais pour votre 2ème solution ("le dernier à raison") : il n'y a pas de problème ?

Par exemple :

Code :

1
2
3
4
5
 
Utilisateur 1  : lit article A   Quantité : 12
Utilisateur 2  : lit article A   Quantité : 12 
Utilisateur 1  : supprime article A
Utilisateur 2  : modifie quantité article A --> plantage

Avant la modification, vous relisez l'article A pour voir s'il existe encore ? Je me trompe quelque part ?

[Barbibulle]

Non dans le cas de suppression en effet l'utilisateur 2 aura un exception.

Ce qui est vrai également dans la solution 3. Car les utilisateurs travaillant chacun de leur coté avec le cache local, lors de l'envois des caches il y a des risques de confits de ce type. C'est pourquoi c'est une solution à réserver que pour les données qui ne sont pas très volatiles.