Par défaut EJB mode de transaction pour les méthodes asynchrones?

  1. Quand j'ai un @Asynchronous méthode d'un EJB, et je ne spécifiez pas le @TransactionAttribute, alors, comment fonctionne exactement la poignée du récipient de la transaction limites? De toute évidence, il ne peut pas utiliser le thread appelant transaction, de sorte que fait-il?

  2. Même question, mais en ce qui concerne les méthodes qui sont déclenchés par le TimerService.

EDIT: je pense que j'ai formulée que mal. Je sais déjà que le mode par défaut est "OBLIGATOIRE". Il devrait donc être sûr de supposer que ces méthodes sera toujours à l'intérieur d'une transaction. Mais ma question est, quel est l'opération du cycle de vie ressemble? Le conteneur de créer une nouvelle opération pour chaque appel? Ou faut-il ré-utiliser la même opération pour tous les appels sur un asynchrones thread de travail? Si c'est le dernier, puis lors de la transaction être fermés?

InformationsquelleAutor Mike Baranczak | 2010-10-25
  1. 44

    Similaire à un fichier MDB la transaction est démarrée par le conteneur, juste avant votre @Asynchronous, @Schedule ou @Timeout méthode (et applicable intercepteurs) est appelée en fait et commis juste après la méthode (et intercepteurs) complète.

    Comme à l'habitude, la transaction se propage à tous les haricots appelé dans ladite méthode et tous les haricots ces haricots appel, de manière récursive. Bien entendu, d'autres haricots invoquées sont les bienvenus pour modifier la sémantique de transaction de leur méthode d'appel à l'aide de la spécification d'autres @TransactionAttribute paramètres (dire REQUIRES_NEW, ou NOT_SUPPORTED).

    Note de côté, les transactions ne sont jamais propagé aux haricots avec @TransactionManagement(BEAN). Le conteneur toujours suspendre toute opération en cours avant d'appeler une méthode d'un Bean Géré par Transaction bean.

    • Très agréable et claire réponse. Gros +1
    • S'il vous plaît être conscient que cette réponse semble être contraire à la réponse ci-dessous (peut dépendre de l'EJB de la version).
    • Permettez-moi de savoir où les choses apparaissent à des conflits et je vais mettre à jour la réponse à préciser.
    • My bad, j'ai mal compris votre réponse originale à cette question. Il ne semble pas y avoir aucun conflit maintenant que je l'ai lu à nouveau. Je peux supprimer l'original si vous le souhaitez.. Il pourrait être bon pour mon humilité si vous l'y maintenir bien :).
    • Hehe, pas de soucis. Le plaisir de l'échange. Si vous avez dû lire deux fois, il est probablement de ma faute. 🙂
    • Super réponse, a également eu à le lire deux fois. Pour tous les autres la lecture de ce (comme indiqué ci-dessus et ci-dessous). Une nouvelle Transaction est démarrée pour la méthode asynchrone.

    InformationsquelleAutor David Blevins
  2. 35

    De EJB 3.1 spec.

    4.5.3 Transactions

    Client contexte de transaction n'est pas de se propager avec une méthode asynchrone invocation. De la Fève de Développeur, il n'y a jamais un contexte de transaction qui se jette dans le client. Cela signifie, par exemple, que la sémantique de la NÉCESSAIRE attribut de transaction sur une méthode asynchrone sont exactement les mêmes que REQUIRES_NEW.

    InformationsquelleAutor Przemysław Pelczar