openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ajay Aggarwal" <aaggar...@covergence.com>
Subject RE: OptimisticException question
Date Thu, 29 Nov 2007 14:42:33 GMT
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: plinskey@gmail.com [mailto:plinskey@gmail.com] 
Sent: Wednesday, November 28, 2007 9:24 PM
To: users@openjpa.apache.org
Subject: Re: OptimisticException question

Hi,

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

-Patrick

On 11/28/07, Adam Hardy <adam.sql@cyberspaceroad.org> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message