openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: How to get beter stacktraces????
Date Tue, 24 Feb 2009 01:23:05 GMT
I've see in these cases that it's hard to get the details of what went  
wrong since the error is being reported to you at commit time while  
the error actually occurred earlier.

Getting the earlier stack trace is what is needed, and this requires  
some coordination between WebLogic and OpenJPA.

In EJB, there is a separation of concerns (security, blah blah) that  
means that errors that occur while processing a request are not  
reported to the caller of the business method. The earlier OpenJPA  
exception may have been swallowed by WebLogic. [Certain attack models  
might make use of the specific error stack to discover privileged  
information about the implementation of the system.] Of course, this  
doesn't help the current model which is not trying to attack the  
system, but debug it. So to find the underlying error you may have to  
activate some server side debug tracing and/or logging.

The WebLogic folks might be able to help with the logging  
configuration needed to get the info you need.

Craig

On Feb 23, 2009, at 4:04 PM, kurt_cobain wrote:

>
> Yeah I saw those; but in tracing down into the code, I can see that an
> exception actually never gets thrown. What I get is an exception from
> weblogic like this:
>
> Feb 23, 2009 5:00:01 PM CST> <Error> <EJB> <BEA-010026> <Exception
 
> occurred
> during commit of transaction Name=[EJB
> com.... 
> (com 
> ...EntityName)],Xid=BEA1-0064C38439F43057A4BD(1453943),Status=Rolled
> back. [Reason=<1.0.0 fatal store error>
> org.apache.openjpa.util.StoreException: The transaction has been  
> rolled
> back.  See the nested exceptions for details on the errors that
> occurred.],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since
> begin=0,seconds
> left 
> = 
> 30 
> ,XAServerResourceInfo 
> [weblogic 
> .jdbc 
> .wrapper 
> .JTSXAResourceImpl 
> ]= 
> (ServerResourceInfo 
> [weblogic 
> .jdbc 
> .wrapper 
> .JTSXAResourceImpl 
> ]= 
> (state 
> = 
> rolledback 
> ,assigned 
> =AdminServer),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@866d46,re- 
> Registered
> =
> false),SCInfo[base_domain 
> + 
> AdminServer 
> ]=(state=rolledback),properties=({weblogic.transaction.name=[EJB
> com...sessionBean.methodName(package.Class)],
> weblogic 
> .jdbc 
> = 
> t3 
> :// 
> 10.200.10.89 
> : 
> 7001 
> }),OwnerTransactionManager 
> =ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=AdminServer 
> +10.200.10.89:7001+base_domain+t3+,
> XAResources={TagStore, LEGACYHOSTDS, VPS,
> weblogic.jdbc.wrapper.JTSXAResourceImpl,
> CSCUD1},NonXAResources={})],CoordinatorURL=AdminServer 
> +10.200.10.89:7001+base_domain+t3+):
> weblogic.transaction.RollbackException: The transaction has been  
> rolled
> back.  See the nested exceptions for details on the errors that  
> occurred.
> 	at
> weblogic 
> .transaction 
> .internal 
> .TransactionImpl.throwRollbackException(TransactionImpl.java:1818)
> 	at
> weblogic 
> .transaction 
> .internal 
> .ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:333)
> 	at
> weblogic 
> .transaction 
> .internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:227)
> 	at
> weblogic 
> .ejb 
> .container 
> .internal.BaseRemoteObject.postInvoke1(BaseRemoteObject.java:607)
> 	at
> weblogic 
> .ejb 
> .container 
> .internal 
> .StatelessRemoteObject.postInvoke1(StatelessRemoteObject.java:57)
> 	at
> weblogic 
> .ejb 
> .container 
> .internal.BaseRemoteObject.postInvokeTxRetry(BaseRemoteObject.java: 
> 427)
>
> -- 
> View this message in context: http://n2.nabble.com/How-to-get-beter-stacktraces-----tp2375022p2375201.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message