2010-11-17 5 views
0

J'en ai un bizarre ici. J'utilise nhibernate et mon problème est que sur les insertions de données plus importantes, aucune exception n'est levée, il n'y a pas de données dans la table, MAIS les clés d'identité sont utilisées. Donc, quand j'insère manuellement l'enregistrement suivant, la clé d'identité saute quelques-uns comme si les données étaient importées et supprimées?!?!nHibernate Data Insert Problème/Mystère

Voici quelques choses à considérer: - Je l'extraction de données à partir d'un service Web de sorte que chaque élément prend un certain temps avant qu'il ne soit appelé la marque persistante - Selon l'élément auquel il est soit un insert ou d'une mise à jour - J'utilise un foreach pour parcourir la collection récupérée avant de vérifier si c'est une mise à jour ou une insertion (ie j'essaie de remplir une entité ou de créer une nouvelle instance puis d'appeler make persistante à la fin.) - le code fonctionne car les données sont insérées sur des lots plus petits et sont visibles dans la base de données. Pour les importations qui prennent un peu plus de temps, elles sont toujours complètes sans aucune exception mais il n'y a pas de données visibles mais seulement la clé d'identité a été reprise par ce qui aurait été inséré et visible.

Quelqu'un peut-il expliquer ce qui se passe ici? Comme je ne reçois aucune exception je n'ai aucun moyen de diagnostiquer ceci, aucune aide ou suggestion très appréciée!

Répondre

0

Les clés primaires avec IDENTITY et une transaction annulée expliqueraient les clés manquantes. Ils ont été insérés, puis supprimés à nouveau, soit parce qu'une erreur ultérieure a provoqué une annulation, soit parce que la transaction a expiré, comme le suggère James. Ceci est discuté here.

Votre véritable problème semble être l'erreur silencieuse. Souffrez-vous des exceptions avec une capture vide? Votre prise pourrait-elle être une exception? Si ce n'est déjà fait, je recommande d'ajouter log4net à votre projet avec un simple appender (sink). NHibernate écrit tout ce qu'il fait à log4net s'il est présent (utile pour le débogage, mais ne le laisse pas en production). Alternativement, comme déjà suggéré, vous pouvez profiler votre SQL.

+0

Merci de votre réponse à cette question très précisément. le lot a été enveloppé dans une seule transaction, donc votre suggestion de la restauration doit être exactement ce qui se passait. En fait, une exception a été interceptée manuellement et était due à des entités devant être expulsées pour que la prochaine mise à jour/insertion se produise. Merci pour tous ceux qui ont répondu et tout votre temps! – Sid

0

Je ne peux pas penser à ce qui pourrait se passer du haut de ma tête. Avez-vous un profileur SQL? Si vous le faites et que vous pouvez régulièrement reproduire ce problème lors de l'exécution du profileur pendant qu'il se produit, vous devez vous informer de ce qui se passe. Si ce n'est pas le cas, vous pouvez écrire des triggers d'insertion/suppression pour garder une trace de ce qui se passe dans la table.

0

Quelle est votre stratégie de génération PK? (Sachant que cela pourrait aider à expliquer pourquoi les PK sont épuisés.) Au-dessus de ma tête, il semble que votre transaction expire. Quelques façons de contourner ce problème ...

  • Activez la mise à jour par lots via adonet.batch_size dans hibernate.cfg.xml en supposant que votre fournisseur de base de données le supporte. Les fournisseurs SQL Server et Oracle le font définitivement. Beaucoup d'autres ne le font pas.
  • Récupère toutes les données du service Web et ne commence pas à insérer/mettre à jour vos objets tant que vous n'avez pas toutes les données. Cela vous aidera à raccourcir votre transaction db car vous n'attendrez pas sur le service Web.
  • Envisagez de fractionner un lot plus important en plusieurs lots plus petits si votre logique métier le permet. Étant donné que de petits lots fonctionnent, il peut être judicieux de valider votre transaction et d'en créer une nouvelle tous les éléments X.