Issue Details (XML | Word | Printable)

Key: GLASSFISH-19050
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: marina vatkina
Reporter: rgirsten
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Glassfish swallows RuntimeException thrown in SynchronizationListener.beforeCompletion

Created: 04/Sep/12 01:48 PM   Updated: 07/Sep/12 10:08 PM   Resolved: 07/Sep/12 10:08 PM
Component/s: jts
Affects Version/s: 3.1.2, 4.0_b53
Fix Version/s: 4.0_b54

Time Tracking:
Not Specified

File Attachments: 1. GZip Archive demo-proxy-auth-generic.tar.gz (25 kB) 04/Sep/12 01:48 PM - rgirsten


Glassfish, EclipseLink 2.3.2, Oracle Database Server 10.x or 11.x

Participants: marina vatkina and rgirsten

 Description  « Hide

I have created an example that demonstrates how to use the EclipseLink feature for
Oracle Database Server Proxy Authentication.
This feature uses database authentication and authorization to secure an application.

On Glassfish the original RuntimeException thrown in an EclipseLink exception handler is not piggybacked with the EJBException that the web client does receive from the failed session bean method call.

[#|2012-09-04T15:08:37.237+0200|WARNING|oracle-glassfish3.1.2||_ThreadID=39;_ThreadName=Thread-2;|javax.ejb.EJBException: Transaction aborted
at com.sun.ejb.containers.BaseContainer.completeNewTx(
at com.sun.ejb.containers.BaseContainer.postInvokeTx(
at com.sun.ejb.containers.BaseContainer.postInvoke(
at com.sun.ejb.containers.BaseContainer.postInvoke(
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(
at $Proxy138.incrementAndReadValue(Unknown Source)
at org.apache.jsp.WEB_002dINF.jsp.write_jsp._jspService(
at org.apache.jasper.runtime.HttpJspBase.service(
at javax.servlet.http.HttpServlet.service(
at org.apache.jasper.servlet.JspServletWrapper.service(
at org.apache.jasper.servlet.JspServlet.serviceJspFile(
at org.apache.jasper.servlet.JspServlet.service(
at javax.servlet.http.HttpServlet.service(
at org.apache.catalina.core.StandardWrapper.service(
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(
at org.apache.catalina.core.ApplicationDispatcher.invoke(
at org.apache.catalina.core.ApplicationDispatcher.processRequest(
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(
at org.apache.catalina.core.ApplicationDispatcher.dispatch(
at org.apache.catalina.core.ApplicationDispatcher.forward(
at javax.servlet.http.HttpServlet.service(
at javax.servlet.http.HttpServlet.service(
at org.apache.catalina.core.StandardWrapper.service(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.core.StandardPipeline.doInvoke(
at org.apache.catalina.core.StandardPipeline.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.doService(
at org.apache.catalina.connector.CoyoteAdapter.service(
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(
at com.sun.grizzly.http.ProcessorTask.doProcess(
at com.sun.grizzly.http.ProcessorTask.process(
at com.sun.grizzly.http.DefaultProtocolFilter.execute(
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(
at com.sun.grizzly.DefaultProtocolChain.execute(
at com.sun.grizzly.DefaultProtocolChain.execute(
at com.sun.grizzly.http.HttpProtocolChain.execute(
at com.sun.grizzly.ProtocolChainContextTask.doCall(
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(
at com.sun.grizzly.util.AbstractThreadPool$
Caused by: javax.transaction.RollbackException
at com.sun.jts.jta.TransactionManagerImpl.commit(
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction(
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(
at com.sun.ejb.containers.BaseContainer.completeNewTx(
... 54 more

The README file of the example explains how to setup the example.
The problem can be reproduced by logging in as user "proxyuser" and password "test" and then clicking on "write".
The user "proxyuser" does not have privileges to write and therefore the JDBC driver will raise an exception that indicates that the privileges are not sufficient.

On WebLogic Server the example does display the correct error message of the root cause exception on the error page.

marina vatkina added a comment - 05/Sep/12 12:33 AM

Can you try the scroll through the causes? I think we fixed it in the transaction code, but the EJB container only reports the actual transaction failure (javax.transaction.RollbackException), which is fine.

rgirsten added a comment - 05/Sep/12 09:13 AM

The web client error page walks down the exception chain and prints the root exception error message.
The client gets EJBException with RollbackException. The root cause exception is missing.
I have tried to setup a simpler example which is simply violating a primary key constraint (unique key violation) in a transaction. But in this case the client will receive the complete chain of exceptions including the root cause.
So, somewhat the behavior of Glassfish seems to be inconsistent.
But without having the complete exception chain available, the client cannot handle or report an application exception.
It is pretty normal for persistence frameworks to plug into JTS by using a SynchronizationListener with the beforeCompletion and afterCompletion method. Also it is normal that such persistence framework does call setRollbackOnly if the processing of the beforeCompletion and afterCompletion actions was throwing an exception.

marina vatkina added a comment - 07/Sep/12 04:59 AM - edited

Can you attach a simple test case? Are you using XA or non-XA resources?

marina vatkina added a comment - 07/Sep/12 05:04 AM

I have even a junit test case that verifies that an exception from beforeCompletion is attached to the RollbackException...

rgirsten added a comment - 07/Sep/12 09:31 AM

I have tried to simplify my example but I was not able to.
My example uses an XA data source for the transaction that throws the RuntimeException in the eclipselink exception handler when it detects the
SQLSyntaxErrorException: ORA-01031: insufficient privileges
My RuntimeException does not piggyback the SQLSyntaxErrorException. But this is not the problem.
The problem is that the RollbackException does not piggyback the root cause exception which is the RuntimeException.
If I remove the eclipselink exception handler by putting the persistence.xml property in comments then I have the problem that the SQLSyntaxErrorException is not piggybacked by the RollbackException.
There is very little Glassfish specific that eclipselink is doing.
The SunAS/Glassfish support classes do provide Glassfish specific methods to lookup the TransactionManager and to unwrap JDBC connections.

marina vatkina added a comment - 07/Sep/12 09:40 PM

I can reproduce it with 2 XA resources, but it's not clear yet why junit test doesn't catch it

marina vatkina added a comment - 07/Sep/12 09:48 PM

Interestingly enough the unit test calls tx.commit() and that path attaches the cause. TM.commit() doesn't

marina vatkina added a comment - 07/Sep/12 09:52 PM

Transaction.commit was fixed by

marina vatkina added a comment - 07/Sep/12 10:08 PM

Fixed on trunk with rev 55854.

To make the same change in 3.1.2x line 333 in src/main/java/com/sun/jts/jta/ should be changed as follows:

  • throw new RollbackException();
    + RollbackException rbe = new RollbackException();
    + Throwable cause = ex.getCause();
    + if (cause != null) { + rbe.initCause(cause); + }
    + throw rbe;