Well, I am seeing OptimisticException and not OptimisticLockException.
What's the difference between the two? Below is my trace, if that's any
hint as to why I am not getting OptimisticLockException. My environment
is BEA WLS 6.1. 

Thanks.



####<Nov 27, 2007 5:18:57 PM EST> <Error> <EJB> <aaggarwal>
<AdminServer> <[ACTIVE] ExecuteThread: '0' for queue:
'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <>
<1196201937032> <BEA-010026> <Exception occurred during commit of
transaction Name=[EJB
com.covergence.soa.covapi.sesscfg.SessionConfigBean.getSessionConfig(com
.covergence.soa.utils.SerJavaSipMessageType)],Xid=BEA1-000076951D12E126C
EB7(46083264),Status=Rolled back. [Reason=<2|false|0.9.7>
org.apache.openjpa.util.OptimisticException: Optimistic locking errors
were detected when flushing to the data store.  The following objects
may have been concurrently modified in another transaction:
[com.covergence.soa.covapi.userpolicy.User-com.covergence.soa.covapi.use
rpolicy.User-1]],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since
begin=2,seconds
left=29,SCInfo[ajayProduction+AdminServer]=(state=rolledback),properties
=({weblogic.transaction.name=[EJB
com.covergence.soa.covapi.sesscfg.SessionConfigBean.getSessionConfig(com
.covergence.soa.utils.SerJavaSipMessageType)]}),OwnerTransactionManager=
ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=AdminServer+172.30.
0.202:7001+ajayProduction+t3+admin+7001+,
XAResources={WLStore_ajayProduction__WLS_AdminServer},NonXAResources={})
],CoordinatorURL=AdminServer+172.30.0.202:7001+ajayProduction+t3+admin+7
001+): weblogic.transaction.RollbackException: Optimistic locking errors
were detected when flushing to the data store.  The following objects
may have been concurrently modified in another transaction:
[com.covergence.soa.covapi.userpolicy.User-com.covergence.soa.covapi.use
rpolicy.User-1]
        at
weblogic.transaction.internal.TransactionImpl.throwRollbackException(Tra
nsactionImpl.java:1818)
        at
weblogic.transaction.internal.ServerTransactionImpl.internalCommit(Serve
rTransactionImpl.java:333)
        at
weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransac
tionImpl.java:227)
        at
weblogic.ejb.container.internal.BaseRemoteObject.postInvoke1(BaseRemoteO
bject.java:606)
        at
weblogic.ejb.container.internal.StatelessRemoteObject.postInvoke1(Statel
essRemoteObject.java:57)
        at
weblogic.ejb.container.internal.BaseRemoteObject.postInvokeTxRetry(BaseR
emoteObject.java:426)
        at
com.covergence.soa.covapi.sesscfg.SessionConfigBean_4w7egw_SessionConfig
Impl.getSessionConfig(SessionConfigBean_4w7egw_SessionConfigImpl.java:76
)
        at
jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Lja
va.lang.Object;)Ljava.lang.Object;(Unknown Source)
        at
java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)L
java.lang.Object;(Unknown Source)
        at
weblogic.ejb.container.internal.RemoteBusinessIntfProxy.invoke(RemoteBus
inessIntfProxy.java:63)
        at
$Proxy132.getSessionConfig(Lcom.covergence.soa.utils.SerJavaSipMessageTy
pe;)Lcom.covergence.ws.callouts.SessionConfigType;(Unknown Source)
        at
com.covergence.soa.ws.server.CallOutsImpl.getSessionConfigType(CallOutsI
mpl.java:46)
        at
com.covergence.soa.ws.server.CallOutsImplBase.getSessionPolicy(CallOutsI
mplBase.java:233)
        at
jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Lja
va.lang.Object;)Ljava.lang.Object;(Unknown Source)
        at
java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)L
java.lang.Object;(Unknown Source)
        at weblogic.wsee.jaxws.WLSInvoker.invoke(WLSInvoker.java:50)
        at weblogic.wsee.jaxws.WLSInvoker.invoke(WLSInvoker.java:42)
        at
com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHan
dler.java:247)
        at
com.sun.xml.ws.server.sei.SEIInvokerPipe.process(SEIInvokerPipe.java:97)
        at
weblogic.wsee.jaxws.MonitoringPipe.process(MonitoringPipe.java:98)
        at
com.sun.xml.ws.protocol.soap.ServerMUPipe.process(ServerMUPipe.java:62)
        at
com.sun.xml.ws.server.WSEndpointImpl$1.process(WSEndpointImpl.java:139)
        at
com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter
.java:153)
        at
com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:235)
        at
com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapt
er.java:97)
        at
weblogic.wsee.jaxws.HttpServletAdapter.post(HttpServletAdapter.java:36)
.> 


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 28, 2007 9:24 PM
To: [email protected]
Subject: Re: OptimisticException question

Hi,

The internal exception should be re-wrapped in an
OptimisticLockException.

-Patrick

On 11/28/07, Adam Hardy <[EMAIL PROTECTED]> wrote:
> Ajay Aggarwal on 28/11/07 17:00, wrote:
> > Hi,
> >
> >
> >
> > I wanted to know why openJPA uses
> > "org.apache.openjpa.util.OptimisticException" and not
> > "javax.persistence.OptimisticLockException". In my code I wanted to
> > catch this exception and take appropriate action. However I didn't
want
> > my code to become dependent on OpenJPA. I wanted to limit OpenJPA
> > dependency to persistence.xml
> >
> > Am I missing something?
>
> Hi Ajay,
>
>
> org.apache.openjpa.persistence.OptimisticLockException
>
> extends
>
> javax.persistence.OptimisticLockException
>
> I would suggest that the circumstances under which OptimisticException
is
> thrown
> would give a clue as to why it and not OptimisticLockException is
being
> used.
>
>
> regards
> Adam
>


-- 
Patrick Linskey
202 669 5907

Reply via email to