EntityManager jette TransactionRequiredException sur merge() dans JBoss bean JSF

J'ai mis en place une application JSF sur JBoss 5.0.1 GA présenter une liste d'Utilisateurs dans une table et de permettre la suppression des utilisateurs individuels via un bouton à côté de chaque utilisateur.

Quand deleteUser est appelé, l'appel est passé à un UserDAOBean qui obtient un EntityManager injecté à partir de JBoss.

Je suis en utilisant le code

public void delete(E entity)
{
    em.remove(em.merge(entity));
}

pour supprimer l'utilisateur (code a c&p à partir d'un tutoriel JPA). Juste appeler em.supprimer(entité) n'a aucun effet et provoque toujours la même exception.

Lorsque cette ligne est atteint, je suis un TransactionRequiredException:

(en ignorant apparemment sans intérêt stacktrace-stuff)

...

20:38:06,406 ERREUR [[Faces Servlet]]
Servlet.service() de la servlet Visages
Servlet jeté exception
javax.la persistance.TransactionRequiredException:
EntityManager doivent être accessibles, dans un
transaction à
org.jboss.jpa.le déploiement.ManagedEntityManagerFactory.verifyInTx(ManagedEntityManagerFactory.java:155)
au
org.jboss.jpa.tx.TransactionScopedEntityManager.de fusion(TransactionScopedEntityManager.java:192)
au
à l'.fhj.l'imt.utils.DAOImplTemplate.supprimer(DAOImplTemplate.java:54)
au
à l'.fhj.l'imt.UserBean.supprimer(UserBean.java:53)
au
soleil.de réfléchir.NativeMethodAccessorImpl.invoke0(Native
La méthode)

...

J'ai déjà essayé d'envelopper un gérés manuellement transaction (em.getTransaction().begin() + .commit() ) autour d'elle, mais cela a échoué car il n'est pas permis dans les conteneur JBoss. Je n'avais pas de succès avec un usertransaction. Des recherches sur le web pour cette question aussi mis en place aucun cas similaire et la solution.

Quelqu'un a vécu quelque chose de semblable avant et trouvé une solution à cela?

"J'ai déjà essayé d'envelopper d'une transaction autour d'elle, mais cela a échoué car il n'est pas permis dans les conteneur JBoss." - ce n'est pas permis? Les Transactions? Pas vrai. Veuillez mettre à jour et de expliquer cela plus en détail.
Et pourquoi pensez-vous qu'il est nécessaire de fusionner avant la suppression d'un objet? Si quelque chose est mal, je serais en désaccord avec ça.
Précisé (je l'espère). Je voulais dire à la gestion manuelle des transactions sur l'EntityManager. En outre, le supprimer(merge()) est présent dans tous les exemples sur le web (même pour Oracle). Néanmoins, essayé un simple de supprimer ce qui provoque toujours la même exception.
Je ne pense pas que je recommande à fusionner. Le sortir et de voir si votre situation s'améliore.
Non, il n'est pas. Désolé.

OriginalL'auteur Kosi2801 | 2009-07-05

8

Trouvé le chaînon manquant.

Il manquait en effet un transaction, mais la solution a été de ne pas utiliser l'EntityManager à manipuler, mais pour ajouter un injecté un usertransaction.
```
@Resource
UserTransaction ut;
...
public void delete(E entity)
{
        ut.begin();
        em.remove(em.merge(entity));
        ut.commit();
}
```
Merci pour toutes les suggestions qui en quelque sorte plus de 100 coins aboutir à cette solution.

Il n'est pas très bonne idée de contrôle de la transaction manuellement, c'est vous code plus détaillé, Java2EE serveur peut le faire pour vous. pourquoi ne pas utiliser les annotations pour cela?
Parce que j'ai essayé. J'ai essayé très dur de trouver une annotation et un réglage qui fonctionne. J'ai essayé d'innombrables variations de @Stateless @Stateful, @Local, @Transactionattribute, etc., aucun n'a fonctionné et dans la plupart des cas causés EntityManager à être injectés pas plus. Je n'ai vraiment aucune idée, ce qui est à l'origine de ce parce que mes précédentes expériences avec Hibernate faire exactement ce que vous dites et de laisser le conteneur de gérer les transactions. Néanmoins, il semble être différent avec JSF et JPA, et puisque cette solution est facile et utilisé uniquement pour les supprimer et d'ajouter, je vais rester avec elle et de ne pas passer plus de temps sur elle.

OriginalL'auteur Kosi2801
2

Sais que c'est une vieille question, mais juste au cas où quelqu'un tombe sur ce comme moi.

Essayer
```
em.joinTransaction();
em.remove(bean);
em.flush();
```
C'est ce que nous utilisons dans tous nos @Stateful haricots.

Si vous êtes à l'aide de soudure, vous pouvez également utiliser @Transactional(TransactionPropagationType.REQUIRED) annotation.

OriginalL'auteur chinto
1

Êtes-vous sûr que vous annotée vous bean avec @Apatride ou de l'enregistrer avec xml?

Essayez d'ajouter de l'opération d'annotation pour vous code, cela peut vous aider:
```
@TransactionAttribute(REQUIRED)
public void delete(E entity)
{
        em.remove(em.merge(entity));
}
```
Mais il semble étrange, parce que c'est la valeur par défaut si vous ne définissez pas explicitement.

Pas de chance avec @TransactionAttribute: Le haricot n'est PAS annotée avec @Stateless mais l'EntityManager est avec @PersistenceContext(unitName = "test). Lorsque j'ajoute le @Stateless à la classe EntityManager n'est pas injecté plus, mais la valeur null.
EJB crée automatiquement une transaction au début de toute EJBean appel de méthode. Par conséquent, si vous n'êtes pas à l'aide d'un EJB ( @Stateless , @Local, etc. avec le conteneur associé), vous devrez créer votre propre transaction.
Si vous voulez que vous haricot était DAO c'est mieux si vous l'annoter avec @Stateless, et d'utiliser @interface Locale. Parce que si si haricot n'est pas @Stateless ou @Statefull alors il n'est pas EJB bean, et la transaction n'est pas géré comme disent Drew. Aussi, si vous les nouvelles dans les EJB prendre un coup d'oeil à son livre "les Enterprise JavaBeans, 3.0" Par Bill Burke, Richard Monson-Haefel
+1 pour vous assurer que vous annotée vous bean avec @Apatride ou de l'enregistrer avec xml?

OriginalL'auteur aindl
0

juste une remarque: nous avons rencontré ce même problème aujourd'hui, s'est avéré quelqu'un avait marqué les EJB comme TransactionAttributeType.NOT_SUPPORTED ET la méthode TransactionAttributeType.NÉCESSAIRES, causant le em.fusion échouer par manque de transaction.

OriginalL'auteur jwenting

Vous devez vous connecter pour publier un commentaire.