La Réalisation De NHibernate Les Transactions Imbriquées Comportement

Question

Je suis en train de réaliser une sorte de transaction imbriquée comportement à l'aide de NHibernate de l'opération de contrôle et de FlushMode options, mais les choses se sont un peu confus après trop de lecture, de sorte que toute confirmation sur les faits que je liste ci-dessous sera très utile.

Ce que je veux, c'est d'ouvrir une grande opération qui se divise en peu de transactions.Imaginez le scénario suivant:

• TX1 ouvre un TX et insère le dossier d'une Personne;
• TX2 ouvre un TX et mises à jour du nom de cette Personne à P2;
• TX2 s'engage;
• TX3 ouvre un TX et mises à jour du nom de cette Personne à P3;
• TX3 restaurations;
• TX1 s'engage;

J'aimerais voir NH envoi de l'INSERT et le TX2 mise à JOUR de la base de données, tout en ignorant ce TX3, comme il l'a été annulée.

J'ai essayé d'utiliser FlushMode = Jamais et seulement rinçage de la session après l'Commence/Engage/Restaurations ont été demandés, mais NH toujours de mise à jour de la base de données avec l'objet final de l'état, indépendant de livraisons et de restaurations. Est-ce normal?N'NH vraiment ignore le contrôle de transaction lorsque l'on travaille avec FlushMode = Jamais?

J'ai aussi essayé d'utiliser FlushMode = s'Engager et d'ouverture les transactions imbriquées, mais j'ai découvert que, parce que ADO.NET, les transactions imbriquées sont, en fait, toujours la même transaction.

Notez que je ne cherche pas à atteindre un "tout ou rien" de comportement.Je suis à la recherche de plus d'un point de sauvegarde façon de travailler. Est-il un moyen de le faire (les points de sauvegarde) avec NH?

Je vous remercie à l'avance.

Filipe

Answer 1

Juste pour ne pas laisser cette question ouverte pour toujours, je vais poster la solution que nous avons adoptée.

Nous avons une unité de travail comme conteneur qui gère la transaction imbriquée comportement.Selon le type de traitement que nous voulons, il crée (ou pas) de nouvelles sessions.Par exemple:

• Continuer en cas d'erreur:si nous voulons que, même si une erreur de transaction les autres s'engage, le UoW conteneur utilise différentes séances pour chaque "opération" et les bouffées de chaleur tous les tx à la fin de ses travaux;
• Rollback en cas d'erreur:si nous voulons que sur une session de restauration (en raison d'une erreur ou d'une entreprise de restauration) à chaque transaction obtient restaurée, le UoW conteneur utilise de la même session pour toutes les transactions imbriquées et restaure tout le monde à la fin.

Il est important de dire que la "transaction" que ce UoW manipule n'est pas le NH (ADO.NET) de transaction directement.Nous avons créé une abstraction d'une transaction, de sorte que la manipulation de code de "votes" si notre transaction peut être engagée ou annulées, mais la véritable action juste se produit à la fin de tout, basé sur l'erreur de stratégie.

Nous savons que cette utilisation n'est pas très commun et ne s'installe que sur des scénarios spécifiques (dans notre cas, c'est un scénario d'intégration avec le traitement par lots), donc je vais maintenant poster le code.Si quelqu'un pense que cette mise en œuvre peut aider, s'il vous plaît, envoyez-moi un message et je serai heureux de partager le code.

En ce qui concerne,

Filipe

Answer 2

NHibernate ne prend pas en charge les transactions imbriquées.Chaque ISession peut avoir au plus une transaction active.Je ne suis pas sûr de ce que vous avez;re tente d'accomplir parce que votre exemple de scénario ne fait pas de sens pour moi.Commettre de transaction 1 après l'insertion aurait le même effet.