Discussion :

[Reisubar]

Bonjour,

Je suis grand débutant dans l'exploitation d'Interbase. J'ai à construire une application multithreadée accèdant à une base de données :

- Un thread effectue des suppression dans la base de données,
- Un thread consulte la base de données
- Un thread effectue des modifications dans la base de données

En fait, ces threads sont gérés par des serveurs TCP Indy et représentent des connexions clientes.

Je me pose un problème au niveau de la gestion des transactions sur cette BD.
Théoriquement, un même client devrait utiliser la même transaction, pour que les suppressions et les modifications puissent être COMMITés ou ROLLBACKées de manière cohérente... Et c'est là que je me pose la question : comment faire ?

Chaque thread devrait avoir son TIbSQL, mais au niveau des TIbTransactions ? Dois-je gérer une liste (TList) de composants, et suivant le client du thread, assigner au TIbSQL la transaction qui lui est liée ? Au niveau du TIbDataBase, vu que normalement tous les threads se le partagent, puis-je utiliser le même pour tous les threads (est-ce threadsafe ?) Bref, au niveau de l'architecture, je sèche un peu.

Si quelqu'un a déjà été confronté au même problèe...

Cordialement,

A.R.

[cmen76]

J'ai un peu de mal à comprendre pourquoi les threads seraient spécialisés par action...
Il me paraîtrait plus sage de dédier un thread à une transaction, ce qui résoudrait ton problème.
L'idée (communément exploitée) est de créer un "pool" (une TList) d'objets database, et de poser un verrou sur l'objet utilisé jusqu'à sa fin d'utilisaton... Un objet gestionnaire de pool se chargeant de proposer un objet libre ou de mettre la requête en attente de libération d'un objet.
Ainsi une transaction SQL s'exécuterait au sein d'un thread unique.
Cordialement.

[Barbibulle]

Je me pose un problème au niveau de la gestion des transactions sur cette BD.
Théoriquement, un même client devrait utiliser la même transaction, pour que les suppressions et les modifications puissent être COMMITés ou ROLLBACKées de manière cohérente... Et c'est là que je me pose la question : comment faire ?

Oui c'est préférable

Chaque thread devrait avoir son TIbSQL, mais au niveau des TIbTransactions ? Dois-je gérer une liste (TList) de composants, et suivant le client du thread, assigner au TIbSQL la transaction qui lui est liée ?

C'est une idée, le tout est de bien gérer les clients qui se deconnectent sans commiter ou rollbacker, votre Transaction associé à ce client va rester ouverte et si dedans il a fait des mises à jour de données, celà pourait poser problème. Au niveau de TIBTransaction on peu définir un timer aubout duquel il effectue un commit ou un rollback. C'est peut etre une solution pour bien fermer les transactions trop longues.
De plus (Ca reste à vérifier) il faudra certainement gérer en plus de votre liste de transaction un TIBSQL (ouvert) associé à chacune de vos transactions ouverte. Car il me semble que s'il n'y a plus d'objet TIB attaché à une TIBTransaction, celle ci se ferme automatiquement en effectuant l'action par defaut (Commit si vous n'avez pas changer la config du TIBTransaction).

Au niveau du TIbDataBase, vu que normalement tous les threads se le partagent, puis-je utiliser le même pour tous les threads (est-ce threadsafe ?) Bref, au niveau de l'architecture, je sèche un peu.

Celà implique que tout vos clients utilisent le même compte USER pour accéder à la base de données. Pourquoi pas surtout si vous ne savez pas à l'avance combien de USER vont se connecter ou si vous ne voulez pas gérer les USERS avec la sécurité interbase mais d'une autre façon.
Par contre je ne vois pas pourquoi utiliser le même TIBDataBase ne serait pas thread safe, vue que chaque thread utilisera sa propre transaction. La seule chose c'est si un thread fait planter la connexion (je ne sais pas pour quel raison) tout le monde est dans les choux d'un autre coté si c'est le serveur qui fait tomber les connexions je ne vois pas ce que ca changerai d'avoir plusieurs connexions.

Maintenant il me semble que faire ce que préconise cmen76 est mieux, c'est à dire un thread non pas par type d'action mais plutot par action_metier. Cad une action qui peux intégrer des MAJ ou delete ou insert ou select et qui ont besoin d'être dans une transaction pour pouvoir être validée ou annulée dans son ensemble. Chaque client connecter instancierait son propre processus d'action metier.

PS : Tu n'as pas l'impression de réinventer la roue ? Ca resemble à ce qu'on peux trouver sur un serveur d'application ce que tu veux faire non ?

[Reisubar]

J'ai un peu de mal à comprendre pourquoi les threads seraient spécialisés par action...
Il me paraîtrait plus sage de dédier un thread à une transaction, ce qui résoudrait ton problème.

C'est pour une application de contrôle de sources (un peu comme CVSUp). Faire plusieurs opérations en parallèle accèlère le traitement des opérations : pendant que mes clients TCP transfèrent des fichiers (un flux d'octets), un autre client TCP reçoit les fichiers à supprimer de la base, etc. Comme Indy (ma librairie Internet) suit un modèle threadé, chaque requête reçue sera forcément dans un nouveau thread. J'en conviens, c'est un peu bordélique. Si après effectivement tout se passe dans le même thread, il n'y a plus de problème puisque je crée mes composants dans chaque thread et que la transaction de la base est "calée" sur le déroulement du thread. Mais on perds les avantages de l'exécution asynchrone du processus.

Merci pour vos précisions. Sur le papier, ca paraissait sympa, en réalité ça me semble un peu difficile à gérer ;-)