Trouver ou insert basé sur clé unique avec Hibernate

J'ai eu un semblable traitement par lots exigence, avec les processus en cours d'exécution sur plusieurs machines virtuelles. L'approche que j'ai utilisée pour cette été comme suit. Il est très bien comme jtahlborn de la suggestion. Cependant, comme vbence souligné, si vous utilisez une transaction IMBRIQUÉE, lorsque vous obtenez la violation de contrainte d'exception, votre session est terminée. Au lieu de cela, j'utilise REQUIRES_NEW, qui suspend la transaction en cours et crée un nouveau, indépendant de la transaction. Si la nouvelle de la transaction est annulée, il ne sera pas affecter la transaction d'origine.

Je suis à l'aide du Printemps TransactionTemplate mais je suis sûr que vous pouvez facilement traduire si vous ne voulez pas une dépendance de Printemps.

public T findOrCreate(final T t) throws InvalidRecordException {
//1) look for the record
T found = findUnique(t);
if (found != null)
return found;
//2) if not found, start a new, independent transaction
TransactionTemplate tt = new TransactionTemplate((PlatformTransactionManager)
transactionManager);
tt.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
try {
found = (T)tt.execute(new TransactionCallback<T>() {
try {
//3) store the record in this new transaction
return store(t);
} catch (ConstraintViolationException e) {
//another thread or process created this already, possibly
//between 1) and 2)
status.setRollbackOnly();
return null;
}
});
//4) if we failed to create the record in the second transaction, found will
//still be null; however, this would happy only if another process
//created the record. let's see what they made for us!
if (found == null)
found = findUnique(t);
} catch (...) {
//handle exceptions
}
return found;
}

OriginalL'auteur Lawrence McAlpin

La Hibernate documentation sur les transactions et les exceptions stipule que tous les HibernateExceptions sont irrécupérables et que la transaction en cours doit être annulée dès que l'on s'est rencontré. C'est ce qui explique pourquoi le code ci-dessus ne fonctionne pas. En fin de compte vous ne devriez jamais attraper un HibernateException sans quitter la transaction et de la fermeture de la session.

Le seul véritable moyen pour accomplir cela, il semblerait serait de gérer la clôture de la session ancienne et la réouverture d'une nouvelle à l'intérieur de la méthode elle-même. Mise en œuvre d'un findOrCreate méthode qui peut participer à une transaction existante et de est sûre dans un environnement distribué paraît impossible l'utilisation d'Hibernate basé sur ce que j'ai trouvé.

OriginalL'auteur Mike Deck

quelques personnes ont mentionné les différentes parties de la stratégie globale. en supposant que vous pouvez généralement s'attendre à trouver un objet existant plus souvent que vous créez un nouvel objet:

• de recherche pour un objet existant par nom. dans ce cas, le retour
• commencer imbriquée (séparée) de la transaction
  • essayez d'insérer un nouvel objet
  • commit transaction imbriquée
• attraper l'échec de transaction imbriquée, si quoi que ce soit mais de violation de contrainte, re-jeter
• sinon de recherche pour un objet existant par un nom et de le retourner

juste pour préciser, comme l'a fait remarquer dans une autre réponse, la "niche" de la transaction est en fait une transaction distincte (de nombreuses bases de données ne sont pas même d'un véritable soutien, les transactions imbriquées).

OriginalL'auteur jtahlborn

Eh bien, voici une façon de le faire - mais il n'est pas approprié pour toutes les situations.

• Foo, supprimer le "unique = true" attribut sur name. Ajouter un horodatage est mise à jour à chaque insertion.
• Dans findOrCreate(), n'est pas la peine de vérifier si l'entité avec le même nom existe déjà - il suffit d'insérer un nouveau à chaque fois.
• Lors de la recherche de Foo cas par name, il peut y avoir 0 ou plus avec un nom donné, de sorte que vous suffit de sélectionner le plus récent.

La bonne chose à propos de cette méthode est qu'elle ne nécessite pas de blocage, donc tout devrait fonctionner assez rapide. L'inconvénient est que votre base de données sera jonché avec les enregistrements obsolètes, de sorte que vous peut avoir quelque chose à faire quelque part d'autre à traiter avec eux. Aussi, si d'autres tables se référer à Toto par son id, puis ce sera à vis de ces relations.

OriginalL'auteur Mike Baranczak

Je voudrais essayer de la stratégie suivante:

A. Démarrer une opération principale (au temps 1)

B. Démarrer une sous-transaction (au temps 2)

Maintenant, tout objet créé après le temps 1 ne sera pas visible dans l'opération principale. Ainsi, lorsque vous vous

C. Créer de nouveaux course-état de l'objet, de s'engager sous-transaction

D. Gérer les conflits par le démarrage d'une nouvelle sous-transaction (temps 3) et l'obtention de l'objet à partir d'une requête (le sous-transaction du point B est maintenant hors de portée).

seulement retourner l'objet clé primaire, puis utiliser l'EntityManager.getReference(..) pour obtenir l'objet que vous allez utiliser pour l'opération principale. Vous pouvez également démarrer l'opération principale après le D; il n'est pas totalement clair pour moi dans combien de conditions de course, vous aurez au sein de votre opération principale, mais le ci-dessus devrait permettre de n fois B-C-D dans un "grand" de la transaction.

Note de ce que vous pourriez voulez faire du multi-threading (un thread par CPU) et puis vous pouvez probablement réduire ce problème considérablement à l'aide d'un partagées statique de cache, pour ces types de conflits - et le point 2 peut être gardé 'optimiste', c'est à dire ne pas faire un .trouver des (..).

Modifier: Pour une nouvelle opération, vous avez besoin d'une interface d'EJB appel de la méthode annotée avec le type d'opération REQUIRES_NEW.

Modifier: vérifiez que les getReference(..) fonctionne comme je le pense.

OriginalL'auteur ThomasRS