HOAB

Le problème :

Lors de l'exécution d'un service, l'erreur suivante apparait :

javax.resource.ResourceException: IJ000459: Transaction is not active

Plusieurs liens internet en parle, c'est systématiquement lié à JBoss puisque c'est lui qui gère ce niveau transactionnel en mode container et que le code IJ... c'est du JBoss.

Solution :

En court : Bien tracer toutes les erreurs, une erreur précédent celle-ci est survenue et a mis la transaction en rollback-only (on pourrait rapprocher ce problème de ceci).

En long :

Contexte d'exécution : JBoss 7.1.1, Hibernate 4.1.6

• Si une exception est remontée par hibernate, elle met par défaut la transaction au statut ABORT
• L’erreur de haut niveau lorsqu’on essaye d’utiliser une transaction avec le statut ABORT (en lecture ou écriture) est : « Could not open connection »

Ce genre de cas arrive lorsque la gestion d’erreur est mal codée (le service de haut niveau ne se termine par immédiatement et on essaye de mettre à jour quelque chose en base…)

Scénario d'exemple :

1. 1ere erreur hibernate :
   • EJB Invocation failed on component
   • javax.persistence.OptimisticLockException
   • Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect):
2. 2eme erreur :
   • EJB Invocation failed on component
   • javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Could not open connection
   • org.hibernate.exception.GenericJDBCException: Could not open connection
   • java.sql.SQLException: javax.resource.ResourceException: IJ000460: Error checking for a transaction
   • javax.resource.ResourceException: IJ000460: Error checking for a transaction
   • javax.resource.ResourceException: IJ000459: Transaction is not active: tx=TransactionImple  <.... ActionStatus.ABORT_ONLY >

Lorsque l’exception numéro 1 est arrivée, votre transaction devient inutilisable, pas la peine d'essayer de faire autre chose avec.

Exemple de code incorrect :

Pour tous les objets

     Try {

           Mise à jour objet

     } catch() {

           Logger l’erreur. // Pour rappel, on loggue bien sur les informations fonctionnelles ET techniques (pile d’exception)

     }

Fpour

Mise à jour d’un statut OK ou KO <= impossible si la ligne « mise à jour objet » à mis la transaction en rollback.

Solution pour cet exemple :

1. sortir de la boucle en remontant l'erreur, ne pas mettre à jour de statut (rien n’est mis à jour)
2. sortir de la boucle en remontant l'erreur, les statuts sont stockés au fur et à mesure et mis à jour dans nouvelle transaction
3. tracer l’erreur, continuer la boucle, les statuts sont mis à jour en même temps que l'objet
4. et bien d'autres cas possibles suivant votre fonctionnel...

Le problème :

Un EJB singleton qui sert de cache remonte une erreur avec JBoss 7.1.1 :

EJB Invocation failed on component XXXX for method public java.lang.Object:
javax.ejb.EJBTransactionRolledbackException: JBAS014373: EJB 3.1 PFD2 4.8.5.5.1
concurrent access timeout on org.jboss.invocation.InterceptorContext$Invocation@398e7b17 
- could not obtain lock within 5000MILLISECONDS

Solution :

Tout est déjà écrit bien sur, encore aurait-il fallu le lire :)
Par défaut les EJB @Singleton sont

1. @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)

2. protégés par un @Lock(LockType.WRITE)

donc les méthodes sont synchronisés par le container. On peut

• soit passer la méthode ou la classe en LockType.READ,
• soit passer en Bean-managed (@ConcurrencyManagement(ConcurrencyManagementType.BEAN)). Là c'est vous qui gérer le tout.

Pour reproduire systématiquement, il suffit de mettre un sleep de 6s dans la méthode problématique.

Note:

• Si le pool des ejb n'est pas assez grand on a un permit timeout et non un concurrent ascess timeout.
• Le timeout sous JBoss est configuré dans cette section très intéressante :

<subsystem xmlns="urn:jboss:domain:ejb3:1.2">
            <session-bean>
                <stateless>
                    <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
                </stateless>
                <stateful default-access-timeout="5000" cache-ref="simple"/>
                <singleton default-access-timeout="5000"/>
            </session-bean>
            <pools>
                <bean-instance-pools>
                    <strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                    <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                </bean-instance-pools>
            </pools>
            <caches>
                <cache name="simple" aliases="NoPassivationCache"/>
                <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
            </caches>
            <passivation-stores>
                <file-passivation-store name="file"/>
            </passivation-stores>
            <async thread-pool-name="default"/>
            <timer-service thread-pool-name="default">
                <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
            </timer-service>
            <remote connector-ref="remoting-connector" thread-pool-name="default"/>
            <thread-pools>
                <thread-pool name="default">
                    <max-threads count="10"/>
                    <keepalive-time time="100" unit="milliseconds"/>
                </thread-pool>
            </thread-pools>
        </subsystem>