[EJB3] Could not execute JDBC batch update

Version imprimable

Salut,

Tout d'abord, voici la méthode doGet() de ma servlet de test:

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
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        PrintWriter out = response.getWriter();

        out.println("début");
        System.out.println("début*********************");

        User romUser = new User("rom", "rom", "rom", "rom", "rom1v@yahoo.fr", true, 500);
        Store fnacStore = new Store("FNAC", "Toulouse", "La fnac de Toulouse", null);
        Product computerProduct = new Product("computer", 100000, fnacStore, 6, "standard computer");

        UserFacade userFacade = EjbLocator.getLocator().getUserFacade();

        fnacStore.persist();
        computerProduct.persist();
        romUser.persist();

        romUser.setFirstName("romain");

         romUser.getCart().addProduct(computerProduct, 5);

        User newUser = new User("2e", "2e", "2e", "2e", "2e@a.c", true, 400);
        newUser.persist();
        newUser.getCart().addProduct(computerProduct, 2);

        // userFacade.updateUser(romUser);
        romUser.update();

        newUser.update();

        out.println(userFacade.getUser(romUser.getId()).getFirstName());
        Collection<ProductQuantity> list = userFacade.getUser(romUser.getId()).getCart().getProducts();
        out.println(list);

        System.out.println("ok");
    }
}

L'erreur se produit lorsque je fais plusieurs update dans la même page.

update() se contente de faire un updateUser() sur l'UserFacade, qui lui fait juste un em.merge(user).

Ce qui est très bisarre, si je vire newUser.update() ou romUser.update() uniquement, sans mettre les 2, ça marche...

Voici l'exception.

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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
20:44:21,859 WARN  [JDBCExceptionReporter] SQL Error: 0, SQLState: null
20:44:21,859 ERROR [JDBCExceptionReporter] failed batch
20:44:21,859 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update
	at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:249)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142)
	at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
	at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
	at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
	at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
	at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515)
	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:109)
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:199)
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:85)
	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1181)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:134)
	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
	at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:175)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:193)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
	at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:102)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:214)
	at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79)
	at $Proxy58.updateUser(Unknown Source)
	at ejb.User.update(User.java:270)
	at test.TestsUnit.doGet(TestsUnit.java:83)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:174)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:86)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
	at java.lang.Thread.run(Thread.java:619)
Caused by: java.sql.BatchUpdateException: failed batch
	at org.hsqldb.jdbc.jdbcStatement.executeBatch(Unknown Source)
	at org.hsqldb.jdbc.jdbcPreparedStatement.executeBatch(Unknown Source)
	at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeBatch(CachedPreparedStatement.java:478)
	at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:518)
	at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:242)
	... 53 more
20:44:21,875 ERROR [[TestsUnit]] "Servlet.service()" pour la servlet TestsUnit a généré une exception
java.lang.RuntimeException: javax.transaction.RollbackException
	at org.jboss.aspects.tx.TxPolicy.handleEndTransactionException(TxPolicy.java:198)
	at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:180)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:193)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
	at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:102)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:214)
	at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79)
	at $Proxy58.updateUser(Unknown Source)
	at ejb.User.update(User.java:270)
	at test.TestsUnit.doGet(TestsUnit.java:83)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:174)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:86)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
	at java.lang.Thread.run(Thread.java:619)
Caused by: javax.transaction.RollbackException
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1192)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:134)
	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
	at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:175)
	... 38 more

06/03/2007, 22h01
the-gtm

La semantique du merge, ce n'est pas de faire un update : c'est d'attacher un objet à la transaction en cours (et accessoirement de faire les modifs en base si besoin). Probablement que ça foire parce que tu attaches un objet déjà attaché.

Sinon je te recommende de faire ce genre de manips dans une transaction, soit ouverte explicement ( EntityTransaction tx = em.getTransaction()) soit implicitement (en passant par un session bean par exemple).

Pour continuer ce n'est pas très recommendé de mettre les méthodes persist() et autres au niveau des objets du modèle (User, Product ...)
06/03/2007, 22h27
®om

Citation:

Envoyé par the-gtm

Sinon je te recommende de faire ce genre de manips dans une transaction, soit ouverte explicement ( EntityTransaction tx = em.getTransaction())

Où est-ce que je dois faire ça?

EDIT: de toute façon normalement je suis dans une transaction, la preuve j'ai un RollbackException...

Et comment conseilles-tu de faire un "update" si c'est pas avec merge?
06/03/2007, 23h34
*alexandre*

Ce qui t'était conseiller c'est de séparé le coté business de ton applicationm depuis ta servlet tu accèdes à un session bean qui te présente un ensemble de méthodes.

Ce qui t'as été également conseillé c'est de placé l'ensemble du code d'update dans une transaction doGet n'est pas gérer a un niveau transactionel par ton contener J2EE (pas de déclaration explicte par le biais des annotations)

Tu aurais pu cependant définir d'une forme déclarative la gestion de tes transactions, et créant un TransactionManager et définissant déclarativement un ctx.begin cts.commit
06/03/2007, 23h51
®om
Citation:

Envoyé par *alexandre*

Ce qui t'était conseiller c'est de séparé le coté business de ton applicationm depuis ta servlet tu accèdes à un session bean qui te présente un ensemble de méthodes.

Oui, c'est ce que je faisais avant, grâce à

Code:

EjbLocator.getLocator().getProductFacade().addProduct(monProduct);

ce qui est quand même assez lourd.
je préfère:

Code:

monProduct.persist();

Certes, normalement pour la façade, on peut faire

Code:

@EJB private ProductFacadeImpl maFacade;

Mais si je mets ça j'ai une erreur de déploiement (avec ou sans le Impl).

Citation:

Envoyé par *alexandre*

Ce qui t'as été également conseillé c'est de placé l'ensemble du code d'update dans une transaction doGet n'est pas gérer a un niveau transactionel par ton contener J2EE (pas de déclaration explicte par le biais des annotations)

Comment ça?

Citation:

Envoyé par *alexandre*

Tu aurais pu cependant définir d'une forme déclarative la gestion de tes transactions, et créant un TransactionManager et définissant déclarativement un ctx.begin cts.commit

Effectivement, en mettant dans ma servlet un attribut

Code:

@PersistenceContext private EntityManager em;

et en mettant:
Code:

1 2 3 4 EntityTransaction trx = em.getTransaction(); trx.begin(); //... trx.commit();
dans mon doGet, ça a l'air de marcher...

EDIT: ah bah en fait non, ça ne déploie même plus:

Code:

Illegal @PersistenceUnit on private javax.persistence.EntityManager test.TestsUnit.em :There is no default persistence unit in this deployment.

(j'ai mis un @PersistenceContext, pas un @PersistenceUnit, qu'est-ce qu'il me raconte)

EDIT2: Il faut faire un session bean TransactionManager, c'est ça???
07/03/2007, 00h01
*alexandre*
Code:

1 2 3 EjbLocator.getLocator().getProductFacade().addProduct(monProduct);
Tu ne sépares rien du tout, tu fais juste un appel.

Etant donné que tu es dans un contexte de code managé JEE, tu peux donc accéder à un EJB session en définissant comme variable private dans ta servlet

@EJB
ProductFacade

Dans ton code doGet tu peux imaginer accéder à une méthode de ta facadem qui concerne notament l'update

par productFacate.update(product)

Par contre il te faudra sélectionner un mode transactionel au niveau de ta facade pour ta méthode update

1)par annotation
2)par programmation

Par annotation tu dois définir dans la définition de ta méthode qui doit être transactionelle

@TransactionAttribute(TransactionAttributeType.REQUIRED)

Je te laisse lire la documentation et API au sujet de TransactionAttributeType
07/03/2007, 00h04
®om
Citation:
Envoyé par *alexandre*

Code:

1 2 3 EjbLocator.getLocator().getProductFacade().addProduct(monProduct);

Tu ne sépares rien du tout, tu fais juste un appel.

Etant donné que tu es dans un contexte de code managé JEE, tu peux donc accéder à un EJB session en définissant comme variable private dans ta servlet

@EJB
ProductFacade
Comme je te l'ai dit, ceci ne marche pas chez moi...

Citation:

Envoyé par *alexandre*

Dans ton code doGet tu peux imaginer accéder à une méthode de ta facadem qui concerne notament l'update

par productFacate.update(product)

Par contre il te faudra sélectionner un mode transactionel au niveau de ta facade pour ta méthode update

1)par annotation
2)par programmation

Et comment faire ceci par annotation par exemple ?

Sinon, on peut envisager sur productFacade une méthode update(Product[]), et je ne fais qu'un appel à update à la fin de la méthode?
07/03/2007, 00h19
*alexandre*

Avant la déclaration de ta méthode du définis (dans ta facade)

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void updateTrucMuch(SomeObject o)

Citation:

Sinon, on peut envisager sur productFacade une méthode update(Product[]), et je ne fais qu'un appel à update à la fin de la méthode?

Je comprend pas le sens de ta question, si ta méthode fait partie de la méthode update de ta facade.

Tout le code qui est déclaré dans un contexte transaction de contener (déclaré par l'annotation)

Est donc placé dans un contexte transactionel.

Citation:

Envoyé par ®om

Citation:

Envoyé par *alexandre*

@EJB
ProductFacade

Comme je te l'ai dit, ceci ne marche pas chez moi...

Voici l'erreur que cela fait lorsque je mets:

Code:

@EJB private ProductFacade productFacade;
Code:

1 2 java.lang.RuntimeException: could not resolve global JNDI name for @EJB for container JeeWeb.war: reference class: ejb.ProductFacadeImpl ejbLink: not used by any EJBs at org.jboss.injection.EjbEncInjector.inject(EjbEncInjector.java:88)

07/03/2007, 00h26
®om

Citation:

Envoyé par *alexandre*

Avant la déclaration de ta méthode du définis (dans ta facade)

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void updateTrucMuch(SomeObject o)

Je comprend pas le sens de ta question, si ta méthode fait partie de la méthode update de ta facade.

Tout le code qui est déclaré dans un contexte transaction de contener (déclaré par l'annotation)

Est donc placé dans un contexte transactionel.

J'ai rajouté @TransactionAttribute(TransactionAttributeType.REQUIRED) sur mon update...

Mon problème, c'est que dans ma façade, j'ai une méthode updateUser(User u).
Jusque là tout va bien.

à partir d'une servlet, je récupère ma facade grâce à EjbLocator.getLocator().getUserFacade().
Sur cette façade, je fais .update(monUser1);

Jusque là tout va bien.

Maintenant, je fais .update(monUser2);

et là tout va mal... RollbackException...

Pourrais-tu me donner un petit exemple pour réaliser PLUSIEURS updates dans la même servlet stp, en utilisant une transaction ou n'importe quoi d'autre...?
07/03/2007, 00h27
*alexandre*

Si dans le contexte de ton appel à @EJB tu n'est pas dans du code managé tu dois faire un appel explicite par JNDI,

Je t'invite a lire la documentation sur EJB ...

J'ai débuté l'apprentissage d EJB 3.0 en même temps que toi ...
07/03/2007, 00h28
®om

Citation:

Envoyé par *alexandre*

Si dans le contexte de ton appel à @EJB tu n'est pas dans du code managé tu dois faire un appel explicite par JNDI,

C'est ce que je fais (avec mon EjbLocator, il fait un ctx.lookup(machin)).
Mais en quoi ma servlet n'est pas du code managé?
07/03/2007, 00h29
*alexandre*

Ca n'a aucun sens d'utiliser EjbLocator.getLocator().getUserFacade()

je sais pas ou tu as pu voir ca
07/03/2007, 00h31
*alexandre*

Citation:

Envoyé par ®om

C'est ce que je fais (avec mon EjbLocator, il fait un ctx.lookup(machin)).
Mais en quoi ma servlet n'est pas du code managé?

1) EJBLocator ne devrait representé qu'un lookup sur ton EJB lors de code non managé

2)Code non managé = Code non executé par le contener JEE.

Ta servlet devrait pouvoir être capable de loadé tes EJB par le biais d'annotations ou alors tu travailles sur un jdk trafficé ou je ne sais quoi

Lis la doc ...

Citation:

Envoyé par *alexandre*

Ca n'a aucun sens d'utiliser EjbLocator.getLocator().getUserFacade()

je sais pas ou tu as pu voir ca

Voici ma classe EjbLocator:

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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
package ejb;
 
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.persistence.FlushModeType;
 
/**
 * Locator d'EJBs.
 */
public class EjbLocator {
 
    /** Instance unique. */
    private static final EjbLocator instance = new EjbLocator();
 
    /** Contexte. */
    private Context ctx;
 
    private final Admin admin;
 
    private final ProductFacade productFacade;
 
    private final StoreFacade storeFacade;
 
    private final UserFacade userFacade;
 
    private final CartFacade cartFacade;
 
    /**
     * Crée un locator d'EJBs.
     * 
     * @throws Error
     *             si le contexte ne peut pas être initialisé.
     */
    private EjbLocator() {
        try {
            ctx = new InitialContext();
        } catch (NamingException e) {
            e.printStackTrace();
            throw new Error(e);
        }
        admin = getEjb(AdminImpl.class, false);
        productFacade = getEjb(ProductFacadeImpl.class);
        storeFacade = getEjb(StoreFacadeImpl.class);
        userFacade = getEjb(UserFacadeImpl.class);
        cartFacade = getEjb(CartFacadeImpl.class);
    }
 
    /**
     * Retourne l'unique instance du locator d'EJBs.
     * 
     * @return Locator d'EJBs.
     */
    public static EjbLocator getLocator() {
        return instance;
    }
 
    /**
     * Retourne la façade d'administration.
     * 
     * @return Façade d'administration.
     */
    public Admin getAdmin() {
        return admin;
        // return getEjb(AdminImpl.class, false);
    }
 
    /**
     * Retourne la façade des produits.
     * 
     * @return Façade des produits.
     */
    public ProductFacade getProductFacade() {
        return productFacade;
        // return getEjb(ProductFacadeImpl.class);
    }
 
    /**
     * Retourne la façade des magasins.
     * 
     * @return Façade des magasins.
     */
    public StoreFacade getStoreFacade() {
        return storeFacade;
        // return getEjb(StoreFacadeImpl.class);
    }
 
    /**
     * Retourne la façade des utilisateurs.
     * 
     * @return Façade des utilisateurs.
     */
    public UserFacade getUserFacade() {
        return userFacade;
        // return getEjb(UserFacadeImpl.class);
    }
 
    CartFacade getCartFacade() {
        return cartFacade;
    }
 
    /**
     * Retourne une façade locale.
     * 
     * @param <T>
     *            Type de la façade.
     * @param ejbClass
     *            Classe de la façade.
     * @return Façade locale.
     */
    private <T> T getEjb(Class<T> ejbClass) {
        return getEjb(ejbClass, true);
    }
 
    /**
     * Retourne une façade.
     * 
     * @param <T>
     *            Type de la façade.
     * @param ejbClass
     *            Classe de la façade.
     * @param local
     *            {@code true} si la façade est locale, {@code false} si elle est remote.
     * @return Façade.
     */
    @SuppressWarnings("unchecked")
    private <T> T getEjb(Class<T> ejbClass, boolean local) {
        try {
            return (T) ctx.lookup("Jee/" + ejbClass.getSimpleName() + ((local) ? "/local" : "/remote"));
        } catch (NamingException e) {
            e.printStackTrace();
            return null;
        }
    }
 
}

07/03/2007, 00h33
®om

Citation:

Envoyé par *alexandre*

2)Code non managé = Code non executé par le contener JEE.

Et ma servlet, elle n'est pas exécutée par le serveur JBoss avant Tomcat?

Citation:

Envoyé par *alexandre*

Ta servlet devrait pouvoir être capable de loadé tes EJB par le biais d'annotations ou alors tu travailles sur un jdk trafficé ou je ne sais quoi

Java SE 6
JAVA EE 5
JBoss 5
EJB3
07/03/2007, 00h33
*alexandre*

Je comprend mieux, tu as définis une classe centralisant tes EJB ...
07/03/2007, 08h22
®om
En fait, un User contient un Cart qui contient des ProductQuantity qui contient un Product.
Chacune de ces classes sont des @Entity.

Le problème, c'estque si les User ont dans leur Cart le même product (et non un différent) et qu'on les update à la suite :
Code:

1 2 java.sql.BatchUpdateException: failed batch at org.hsqldb.jdbc.jdbcStatement.executeBatch(Unknown Source)
07/03/2007, 11h59
®om

Apparemment c'est un bug de HSQLDB:
http://forum.springframework.org/arc...p/t-28645.html

Comment désactiver le batching de HSQLDB?