Je pense à utiliser des transactions dans les applications de WPF (ou de formulaires Windows) à 2 niveaux de la manière suivante:
Nous pouvons commencer une nouvelle transaction lorsque nous ouvrons un nouveau formulaire pour modifier les données, modifier et persist changent de manière transparente dans cette transaction. Ensuite, nous pouvons cliquer sur le bouton "OK" et commettez la transaction, ou "Annuler" et la restauration. Si nous voulons ouvrir une autre fenêtre de dialogue avec ces données, nous pouvons utiliser des transactions imbriquées.
La question est la suivante: est-ce que cette façon d'utiliser des transactions acceptables ou non? Je sais qu'il y a beaucoup de moyens différents de mettre en œuvre une telle logique, mais je voudrais énumérer des avantages et des inconvénients de celui-ci.
5 Réponses :
Les transactions de longue date affectent sérieusement votre capacité à échelle.
J'éviterais si possible.
Comme d'autres l'ont noté, vous ne devez pas conserver une transaction ouverte en attendant la saisie de l'utilisateur.
Non, ne conservez pas une transaction ouverte en attendant la saisie de l'utilisateur. C'est une mauvaise conception et entraînera des problèmes de verrouillage avec vos ressources transactionnelles (base de données).
Vous devez repenser votre approche. Pourquoi auriez-vous la transaction ouverte pendant que l'utilisateur remplit un formulaire? Nous utilisons des transactions pour gérer la concurrence et les verrous sur des ressources partagées. Remplir un formulaire ne se qualifie pas vraiment.
Je suis d'accord avec Mitch n Cheeso, mais il y a toujours une autre façon de mettre le délai d'attente sur la fenêtre, vous pouvez notifier une horloge que si l'utilisateur n'approche pas "OK", la fenêtre sera automatiquement fermée et tout sera annulé. .
La majorité des systèmes où les transactions sont essentielles comme le processus de "réservation" sur la compagnie aérienne, les films, etc., les opérateurs sont censés fermer les transactions dans une durée limitée.
En ce qui concerne la convivialité: s'il y a quelque chose d'être réservé (par exemple, un ticket) et doit être publié après un délai d'attente, une horloge de la fenêtre est acceptable. Même dans ce cas, ne le fermez pas (l'utilisateur ne saura pas ce qui s'est passé) Il suffit de mettre un message et de donner à l'utilisateur un bouton à ré-réserver si possible. Mais si vous ne travaillez pas dans un tel système, la stratégie de verrouillage optimiste est bien meilleure. Laissez l'utilisateur prendre tout le temps dont il a besoin et n'annule pas le formulaire à moins qu'il y ait un problème.
Je suis d'accord, donnant une altération à la fenêtre de la fenêtre est une fonctionnalité supplémentaire, c'est-à-dire un addon UI, mais la fermeture est nécessaire car si l'utilisateur est parti pour une autre tâche ou un réseau de réseau, la base de données conservera inutile la serrure et un autre utilisateur peut souffrir, Il est donc important de fermer la transaction dans les systèmes de réservation.
Voici quelques problèmes que vous pourriez rencontrer si vous allez de cette façon
C'est une pratique découragée. Utilisez
Les transactions de longue date étaient un sujet pour une discussion à chaud dans les universités autour de ... 1980 Je dirais. Le problème est qu'une transaction de longue date crée presque certainement une impasse dans une exécution pessimiste et nécessite presque certainement une résolution compliquée de conflits dans une exécution optimiste (pour les chiffres que vous pouvez consulter Le papier de Jim Grey" Les dangers de la réplication et une solution ", mais peu de blocages augmentent comme la cinquième puissance de la taille de la transaction, et la probabilité d'une collision augmente comme deuxième puissance).
Il y avait maintenant différentes propositions au problème, comme "Sagas" de Salem et Garcia-Molina, "transactions imbriquées" et ainsi de suite ( Un autre papier de Jim Gray "Le concept de transaction: vertus et limitations" a plusieurs pages à ce sujet à la fin). La plupart des propositions traitent d'un modèle de transaction, plus faible que l'acide. Par exemple, "transactions longues" peut avoir à exposer leurs résultats intermédiaires, qui enfreint la propriété d'isolement. Mais aucune des propositions ne l'a vaincu à l'industrie, de même que de dire. Surtout parce que ces techniques n'étaient pas vraiment ... Simplifiant, ni n'étaient pas nécessaires pour résoudre les problèmes commerciaux réels.