IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Wildfly/JBoss Java Discussion :

EJB 3.1, @Singleton, concurrent access timeout


Sujet :

Wildfly/JBoss Java

  1. #1
    Membre confirmé
    Avatar de geforce
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2010
    Messages
    1 055
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2010
    Messages : 1 055
    Points : 559
    Points
    559
    Par défaut EJB 3.1, @Singleton, concurrent access timeout
    Bonjour a tous,

    j'ai mis en place plusieurs ingection @EJB qui utilse un @Singleton
    j'ai le message d'erreur suivant :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    Caused by: javax.ejb.ConcurrentAccessTimeoutException: JBAS014373: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on org.jboss.invocation.InterceptorContext$Invocation@5034d93a - could not obtain lock within 5000MILLISECONDS
    	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:100) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
    	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
    	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
    	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
    	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
    	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
    	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
    	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
    	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
    	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:202) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
    	... 90 more
    y t'il une solution a ce problème bizarre !! c'est quoi mon erreur d'avoir utilisé des @Singleton ?

    Merci

  2. #2
    Membre éprouvé
    Avatar de hasalex
    Homme Profil pro
    Développeur Java
    Inscrit en
    Janvier 2009
    Messages
    879
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Janvier 2009
    Messages : 879
    Points : 1 269
    Points
    1 269
    Par défaut
    Dans un EJB, il n'y a pas de problème de réentrance parce qu'il ne peut pas y avoir d'appels simultanés d'une méthode sur la même instance. Ça ne pose aucun problème quand on a un @Stateless, ça ne pose aucun problème car chacun a sa propre instance. Quand on a un @Singleton, c'est chacun son tour...

    Dans ton cas, un client a voulu accéder à cet EJB alors qu'il était déjà utilisé, et son attente a dépassé la durée du timeout.

    Les questions qu'il faut que tu te poses sont les suivantes :

    • Ai-je vraiment besoin d'un singleton ? Sinon, un stateless serait plus adapté.
    • Ai-je vraiment besoin d'un EJB ? Sinon un bean CDI en @ApplicationScoped serait mieux.
    • Si il faut un EJB et singleton, alors quelle politique de @Lock ? cf. http://docs.oracle.com/cd/E19798-01/...psz/index.html

  3. #3
    Membre confirmé
    Avatar de geforce
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2010
    Messages
    1 055
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2010
    Messages : 1 055
    Points : 559
    Points
    559
    Par défaut
    Citation Envoyé par hasalex Voir le message
    Dans ton cas, un client a voulu accéder à cet EJB alors qu'il était déjà utilisé, et son attente a dépassé la durée du timeout.

    Les questions qu'il faut que tu te poses sont les suivantes :

    • Ai-je vraiment besoin d'un singleton ? Sinon, un stateless serait plus adapté.
    • Ai-je vraiment besoin d'un EJB ? Sinon un bean CDI en @ApplicationScoped serait mieux.
    • Si il faut un EJB et singleton, alors quelle politique de @Lock ? cf. http://docs.oracle.com/cd/E19798-01/...psz/index.html
    Bonjour hasalex et autres,
    J’ai donc finalement choisi d'utilisé du CDI, mais je pose la question suivante y a t'il des possibilités ou des services comme du transactionnel que j'ai perdu en utilisant du cdi a la place des EJB ?! Aussi danse future en compte mettre en place système authentification peut-être avec du JAAS (du moins c'est le plus simple que je voix)

    Merci d'avance pour vos réponses

  4. #4
    Membre éprouvé
    Avatar de hasalex
    Homme Profil pro
    Développeur Java
    Inscrit en
    Janvier 2009
    Messages
    879
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Janvier 2009
    Messages : 879
    Points : 1 269
    Points
    1 269
    Par défaut
    Java EE 7 (CDI 1.1, JTA 1.7) a ajouté l'annotation @Transactionnal. Si tu es avec une version plus ancienne, tu peux faire toi-même une annotation équivalente avec un intercepteur.

  5. #5
    Membre confirmé
    Avatar de geforce
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2010
    Messages
    1 055
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2010
    Messages : 1 055
    Points : 559
    Points
    559
    Par défaut
    Citation Envoyé par hasalex Voir le message
    Java EE 7 (CDI 1.1, JTA 1.7) a ajouté l'annotation @Transactionnal. Si tu es avec une version plus ancienne, tu peux faire toi-même une annotation équivalente avec un intercepteur.
    OK, j'utilise JEE7 puis je crois que @Transactional est une très bonne solution.
    Mais je n'ai pas bien compris la différence entre @javax.transaction.TransactionScoped; et @javax.transaction.Transaction; serait-il possible de donnes quelque éclaircissement ?

    Merci pour vos excellentes réponses.

  6. #6
    Membre éprouvé
    Avatar de hasalex
    Homme Profil pro
    Développeur Java
    Inscrit en
    Janvier 2009
    Messages
    879
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Janvier 2009
    Messages : 879
    Points : 1 269
    Points
    1 269
    Par défaut
    @Transactionnal sert à dire qu'une méthode ou qu'un bean CDI est transactionnel, à la façon d'un EJB.

    @TransactionScoped est concurrent des autres annotations de portée : @RequestScoped, @SessionScoped,...

Discussions similaires

  1. Tomcat 7 Access timeout
    Par HeavyAlex dans le forum Tomcat et TomEE
    Réponses: 0
    Dernier message: 21/03/2012, 13h34
  2. Singleton<T> et appels concurrents
    Par julplemet dans le forum Dvp.NET
    Réponses: 2
    Dernier message: 02/09/2011, 23h59
  3. [WEBLOGIC8.1][EJB] changement du timeout des ejb
    Par mcrbe dans le forum Weblogic
    Réponses: 5
    Dernier message: 27/04/2011, 17h31
  4. accès concurrents access
    Par Qamalito dans le forum Access
    Réponses: 5
    Dernier message: 07/08/2007, 23h54
  5. Accès concurrents Access
    Par Nelya dans le forum Sécurité
    Réponses: 4
    Dernier message: 13/12/2006, 18h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo