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.jtsxaresourcei...@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:[email protected]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to