Java EE (Java Enterprise Edition) General Discussion

Hi all,
I'm using Hibernate as my persistence provider in Glassfish, and I'm getting RollbackException: "transaction marked for rollback" once in a while.

My problem is, it's very hard to find the root cause of such exception, since Hibernate decides to mark the transaction for rollback but the reason why never shows up in Glassfish's log. Hibernate is supposed to throw PersistenceException (wrapped around HibernateException) in case of failure, and mark the transaction for rollback. However, this exception never shows up in the log. Instead, Glassfish complains silently with

EJB5018: An exception was thrown during an ejb invocation

I'm trying to do a simple select query: the resulting class (Vendedor) has a OneToOne relation to Ente, which in turn has a OneToMany relation to Domicilio. Apparently the error comes up when trying to load the OneToMany relation (even though it's default to FetchType.LAZY).

This is my log

01:24:08,574 DEBUG Loader:1904 - done entity load
01:24:08,575 DEBUG TwoPhaseLoad:226 - done materializing entity [inertial.brokers.ejb.estructura.Vendedor#f95a9003-7849-4632-ba68-e19c79115f03]
01:24:08,576 DEBUG StatefulPersistenceContext:860 - initializing non-lazy collections
01:24:08,577 DEBUG AbstractFlushingEventListener:134 - processing flush-time cascades
01:24:08,578 DEBUG AbstractFlushingEventListener:177 - dirty checking collections
01:24:08,620 DEBUG Collections:199 - Collection found: [inertial.brokers.ejb.personas.Ente.domicilios#77fc17f0-1e30-4b0e-a983-118b83c28056], was: [inertial.brokers.ejb.personas.Ente.domicilios#77fc17f0-1e30-4b0e-a983-118b83c28056] (uninitialized)
01:24:08,621 DEBUG AbstractEntityManagerImpl:406 - mark transaction for rollback
EJB5018: An exception was thrown during an ejb invocation on [ControlPersonalBean]
javax.ejb.EJBException: Transaction aborted; nested exception is: javax.transaction.RollbackException: Transaction marked for rollback.
javax.transaction.RollbackException: Transaction marked for rollback.
        at com.sun.enterprise.distributedtx.J2EETransaction.commit(J2EETransaction.java:449)
        at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:371)
..(cut out the very long trace here)...
Caused by: javax.ejb.EJBException: Transaction aborted; nested exception is: javax.transaction.RollbackException: Transaction marked for rollback.
        at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3823)
        at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3596)
        at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1379)
        at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:83)
        at $Proxy109.buscarVendedores(Unknown Source)
        at inertial.brokers.web.produccion.CotizarVehiculoBean.buscarVendedores(CotizarVehiculoBean.java:86)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.el.parser.AstValue.invoke(AstValue.java:187)
        at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
        at com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68)
        ... 47 more

As you can see in the log, Glassfish eats up the exception and instead it blows up when the EJB container tries to commit the (already marked for rollback) transaction and fails.
It seems a collection is being loaded, even though it is NOT marked as EAGER and it is also empty!

As a test, I tried calling the same method from a remote, standalone Swing app-client and the exception is not thrown, but the query returns an empty List (which is not the case with the web client, where the -only- Vendedor matching instance is found).

Maybe Glassfish is eating up the exception or its logging is not properly configured. But I'd like to find out the real reason why the transaction is marked for rollback, so I can correct any errors in my code, because it seems to be OK and I'm done with guessing already.

Thanks!