ava.sql.SQLException: DSRA9350E: Operation Connection.commit is not allowed during a global transact

Version imprimable

26/03/2009, 19h01
motorenshi

ava.sql.SQLException: DSRA9350E: Operation Connection.commit is not allowed during a global transact

Bonjour,

J'ai développé via Rational Developper 7.5 un SessionBean 3 très simple avec une méthode qui utilise un entity bean et son entity manager JPA, pour créer un nouveau record dans la table associée.

La méthode marche et le record est créé en base, mais l'exception suivante m'est systématiquement remontée après sa création :

java.sql.SQLException: DSRA9350E: Operation Connection.commit is not allowed during a global transaction.

Mon EJB est créé par défaut, la seule annotation présente dans mon code est le @Stateless.

J'ai essayé de jouer avec les paramètres de transaction :
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
mais j'obtiens le même résultat que par défaut.

Je ne comprends pas trop d'ou vient le problème. C'est la première fois que j'utilise des EJB3, j'ai deja fait le meme style de code avec des EJB2 sans problèmes..

A votre avis, quelle peut être la source du problèmes? Quels sont les paramètres/annotations que je devrais peut être faire figurer dans mon code?

Merci pour votre aide!

Motorenshi.
27/03/2009, 09h42
longbeach

Fais voir le code de ton stateless session bean et de persistence.xml

Est-ce qu'à un moment tu fais un commit() en dur dans le code ?

C'est un entity bean container-managed ou bean-managed ?

C'est un session bean container-managed, j'imagine, puisque tout est par défaut (j'imagine qu'il faudrait ajouter une annotation pr préciser que l'on implémente un BMP?). En tout cas, l'option de choix entre BMP et CMP ne m'est pas offerte par le wizard EJB de RAD comme pour les EJB 2.x

Pour info, j'utilise un WAS 7 en serveur d'applis, et DB2 9 comme source de données. Une ressource jdbc est correctement déclarée dans WAS pointant vers mon instance de database DB2 (provider type=DB2 Universal JDBC Driver Provider, et Implementation type = Connection Pool Data source (non XA donc))

Voici le code de mon stateless session bean :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
package sessions;
 
import java.util.Date;
import java.util.List;
import java.sql.Timestamp;
 
import javax.ejb.Stateless;
 
import entities.*;
import entities.controller.*;
 
 
/**
 * Session Bean implementation class Circuit
 */
@Stateless
public class Circuit implements CircuitLocal {
 
       // JPA entity bean managers créés par RAD
	private OperationManager opLogMgr;  
	private OperationtypeManager opTypeMgr;
	private composantManager composantMgr;
 
    /**
     * Default constructor. 
     */
    public Circuit() {
        // TODO Auto-generated constructor stub
    }
 
 
    public int daterOperation(String value, String operationName){
    	Date currentDate;
 
    	if(operationName.equals("operation1")){
 
    		currentDate= new Date();
    		Operation operation = new Operation(); 
    		operation.setdate(new Timestamp(currentDate.getTime()));
 
    		opTypeMgr = new OperationtypeManager(); 
 
                //recuperation en database du record correspondant à l'opération dont le nom est transmis en paramètre
    		List <Operationtype> l = opTypeMgr.getOperationtypeByName(operationName);
 
    		Operationtype opType = l.get(0);
    		operation.setOperationtypeid(opType);
    		composantMgr = new composantManager();
    		Composant comp = composantMgr.findComposantByValue(value);
    		operation.setValue(comp);
 
    		try {
    			opLogMgr = new OperationManager();
    			opLogMgr.createOperation(operation);
    		} catch (Exception e) {
    			// TODO Auto-generated catch block
    			e.printStackTrace();
    		}
    		return 0;
    	}
 
    	System.out.println("An error occured during dating");
    	return 1;
    }
 
}

et voici le persistence.xml associé :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
	<persistence-unit name="CircuitEJB">
		<jta-data-source>jdbc/circuit</jta-data-source>
		<class>
		entities.Composanttype</class>
		<class>
		entities.Operation</class>
		<class>
		entities.Operationtype</class>
		<class>
		entities.Composant</class>
	</persistence-unit>
</persistence>

27/03/2009, 13h21
longbeach

je t'ai dis une bêtise, j'ai tapé trop vite.
Les notions de persistence CMP ou BMP ne concernent que les entity beans.
En revanche les notions de transaction CMT / BMT concernent bien les sessions beans.

De toute façon ton problème vient du mode transactionnel en cours, dans tes entity beans et dans ton serveur d'appli.

Faut creuser cette piste là.

Essaies d'ajouter cette annotation sur ton SFSB et dis nous ce que ça donne:

Code:

@TransactionManagement(value=TransactionManagementType.BEAN)

Si ce n'est pas spécifié, par défaut le bean a une gestion des transactions CMT, cad que c'est le container qui gère les transactions.
27/03/2009, 15h00
motorenshi

Avant tout merci pour ton aide.

J'ai donc testé en déclarant mon EJB en tant que bean managed via l'annotation que tu m'as donnée.

Cette fois-ci le record n'est plus du tout inseré, et le méthode s'arrete et remonte une exception sur la ligne :

List <Operationtype> l = opTypeMgr.getOperationtypeByName(operationName);

La dite exception :

com.ibm.db2.jcc.a.SqlException: [jcc][t4][10120][10898][3.52.90] Opération non valide : La méthode result set est fermée. ERRORCODE=-4470, SQLSTATE=null

Cela te parle-t-il?

Merci d'avance.

Motorenshi.
02/04/2009, 10h34
motorenshi

J'ai trouvé :

Les entity manager JPA générés par RAD gèrent eux-mêmes les transactions par défaut. Ils réalisent donc des 'commit' à chaque fois qu'une donnée doit être persistée en database.

Ce qui evidemment entre en conflit avec si on les utilise dans un session container-managed puisque c'est celui-ci qui doit faire le commit...

Il m'a donc juste fallu modifier le code des entity managers en conséquence.

Merci pour votre aide.