XE2 / Datasnap / Firebird / Transactions [Résolu]

Signaler
Messages postés
1284
Date d'inscription
mardi 28 octobre 2003
Statut
Contributeur
Dernière intervention
3 juillet 2015
-
Messages postés
4715
Date d'inscription
dimanche 26 février 2006
Statut
Modérateur
Dernière intervention
27 mars 2018
-
Bonjour,

Je me pose une petite question fonctionnelle sur les applications client serveur développées avec Delphi XE2, en utilisant la technologie Datasnap et une base de donnée firebird.

J'ai un serveur avec un composant base de donnée, une transaction et des query paramétrés d'update, d'insert ou de delete. Dans le client, je pose un TDSProviderConnection, puis un TClientDataSet pour chaque query. Je remets les paramètres dans le TClientDataSet (ceux du query correspondant sur le serveur) et je peux faire mes update, insert et delete. En contrôlant dans ma base sur le serveur, tout se passe à merveille. Je voudrais quand même savoir si je peux (dois ?) gérer les transactions. (Ce n'est pas le cas pour le moment, mais il se pourrait que je doive gérer un commit ou rollback sur un ensemble d'ordre SQL de mise à jour).

Any informations ?

Simon

7 réponses

Messages postés
4715
Date d'inscription
dimanche 26 février 2006
Statut
Modérateur
Dernière intervention
27 mars 2018
13
les transactions sont en principe générées sur un composant "connexion".

ex : avec le TIB_connection

FAccueil.TIB_connection1.DefaultTransaction.CommitRetaining;




cantador
Messages postés
4715
Date d'inscription
dimanche 26 février 2006
Statut
Modérateur
Dernière intervention
27 mars 2018
13
Bonjour,

les transaction sont utiles dès l'instant, où il y déjà plusieurs utilisateurs qui interviennent sur la base de données et si également, les données réclament un niveau de sécurité important.

l'accès à la base peut se faire :
- soit de manière exclusive (ce qui est rarement la cas)
- soit en mode partagé

A partir de ce constat et si bien entendu, plusieurs utilisateurs peuvent modifier une donnée dans un champ d'une table, il est nécessaire alors de fixer des règles et des droits.

les transaction entrent dans ce processus en proposant par exemple d'annuler toute une série de manipulations (ex formulaire) avant la validation dès l'instant, où la règle n'est pas respectée, cette marche arrière se faisant en respectant l'intégrité de la base.

Bref, le retour se fait sans encombres (pas de cracra dans les données..)

cordialement
cantador
Messages postés
1284
Date d'inscription
mardi 28 octobre 2003
Statut
Contributeur
Dernière intervention
3 juillet 2015
13
Cantador,
Merci pour ce petit rappel sur les transactions , mais ma question portait plus sur l'utilisation des transactions à partir d'un client datasnap. Je ne vois pas comment les gérer dans le client, avec les composants TClientDataSet. Puisque tu en parles, (même si à priori ça ne concerne pas encore mon appli), je ne vois pas non plus ou je dois gérer le niveau d'isolement de ma base...

Je me demande, même si ça fonctionne, si le clientdataset est vraiment fait pour des requêtes de mise à jour, ou si je n'ai pas plutôt intérêt à tout gérer côté serveur au moyen de méthodes publiées qui prendraient les requêtes en paramètres...

Simon
Messages postés
4715
Date d'inscription
dimanche 26 février 2006
Statut
Modérateur
Dernière intervention
27 mars 2018
13
Bonjour,
[i]
je ne vois pas non plus ou je dois gérer le niveau d'isolement de ma base... /i

Ah ah..

Il s'agit le plus souvent d'une propriété d'un composant de connexion à la base qui propose en général trois formules possibles.

ex: le TDatabase avec sa propriété TransIsolation :

tiDirtyRead Permet la lecture des modifications non validées de la base de données effectuées par des transactions simultanées. Les modifications non validées ne sont pas permanentes, elles peuvent êtres annulées à tout moment. C'est le niveau le plus bas d'isolement d'une transaction par rapport aux effets d'autres transactions.

tiReadCommitted Permet la lecture des modifications validées (permanentes) de la base de données effectuées par des transactions simultanées. C'est la valeur par défaut de la propriété TransIsolation.

tiRepeatableRead Ne permet qu'une seule lecture de la base de données. La transaction ne peut connaître les modifications effectuées ultérieurement par d'autres transactions simultanées. Ce niveau garantit qu'une fois un enregistrement lu par la transaction, l'enregistrement ne change que si la transaction le change. C'est le niveau maximum d'isolement d'une transaction par rapport aux autres transactions.

et dans ce contexte, je te conseille vivement d'opter pour le niveau
tiReadCommitted.

C'est d'ailleurs le plus simple le plus employé et le plus facile à mettre en oeuvre.

Dans cette option, tout le monde peut modifier et valider.
Autrement dit, c'est le dernier qui passe qui fixe la valeur de la donnée.
Il n'y a donc, ici, aucun blocage ni message intempestif d'erreur.
Il suffit juste pour sécurité de fixer les droits des utilisateurs.

et bien entendu, tu peux utiliser le mode transactionnel :
startTransaction, RollBack, Commit

cantador
Messages postés
1284
Date d'inscription
mardi 28 octobre 2003
Statut
Contributeur
Dernière intervention
3 juillet 2015
13
Ah ouais, c'était bien caché... Clic droit sur la transaction (tibtransaction), "Editeur de transaction", choix "Lire la transaction validée". Vu le comportement de mon programme actuel, je pense que j'avais le niveau d'isolement maxi. C'est bon à savoir merci. Par contre, j'insiste mais je ne peux gérer ça que côté serveur. N'ayant pas de composant transaction sur le client, y a t'il un moyen par exemple de démarrer une transaction à partir du client, de passer des ordres via un ou plusieurs TClientDataSet, et de faire un commit ou un rollback toujours sur le client ?
En gros, existe-t-il, sur le client, un moyen d'atteindre la transaction rattachée au query sur le serveur, auquel est lié mon TClientDataSet sur le client ?
(Si je ne suis pas clair, dis le moi)

Simon
Messages postés
4715
Date d'inscription
dimanche 26 février 2006
Statut
Modérateur
Dernière intervention
27 mars 2018
13
y a t'il un moyen par exemple de démarrer une transaction à partir du client

mais bien sûr et heureusement d'ailleurs, puisque c'est justement fait pour eux principalement.

mais je ne te suis pas bien néanmoins..

ton code compilé est en principe placé et exécuté sur le serveur.
Il peut être lancé bien entendu directement sur le serveur mais aussi à partir du poste client.

Si dans ton programme, tu places des instructions
type starttransaction, Rollback ou RollBackRetaining, ou encore
Commit ou CommitRetaining

elles seront nécessairement prises en compte quelque soit l'endroit où l'exécutable a été lancé.

cantador
Messages postés
1284
Date d'inscription
mardi 28 octobre 2003
Statut
Contributeur
Dernière intervention
3 juillet 2015
13
D'accord, donc à part publier trois méthodes sur le serveur (pour le start, le commit et le rollback) pour chaque transaction que j'utilise, je ne peux pas appeler la transaction à partir du TClientDataset qui est sur mon client...

Simon