java.io.NotSerializableException: weblogic.ejb20.internal.EntityEJBContextImpl

Discussion:

(too old to reply)

Ignacio G. Dupont

2004-12-09 21:53:49 UTC

Hi,

We are currently in the process of moving from Weblogic 6.1 SP5 and
Toplink 3.6.3 to Weblogic 8.1 SP2 and Toplink 9.0.4 and during some test
I have seen a "scaring" stack trace. It seems that, for some reason, a
thing that "uses to work" failed with a very strange error. I tried to
reproduce it but without any success. Besides asking if anybody knows
what could have caused this error I would like to know what the "not
serializable" object is. Is it the EntityEJBContext?

<12-09-2004 4:40' GMT> <Error> <app> <000000> <[thread 5
weblogic.kernel.Default]:Exception:
javax.transaction.TransactionRolledbackException at getXML
javax.transaction.TransactionRolledbackException: EJB Exception: :
java.io.NotSerializableException:
weblogic.ejb20.internal.EntityEJBContextImpl
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:78)
at weblogic.rmi.internal.ServerRequest.copy(ServerRequest.java:218)
at
weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:158)
at
weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:138)
at
app.data.production.ProductionBean_3toa0w_EOImpl_811_WLStub.EJB2DOM(Unknown
Source)

In case it could share some light in the case I will explain a bit what
does the process intended to do:

The general idea is that, given some data (managed with Toplink's 9.0.4
CMP) we take a XML "snapshot" of them (via a custom OBJ2XML class that
has been working for ages without any problem) and "publish" it via JMS
in order to perform asyncronous actions with it. I'm sure this is a,
more than usual, scenario for a lot of folks.

As it seems looking at the stack at some point during some internal
object serialization it fails and rollbacks all the process. The object
being serialized by our side only contains four attributes: a
java.math.BigDecimal for it's primary key, a java.util.Date for
timestamp locking and two simple java.lang.String's

Although I'm pretty sure the problem should not be with the entity bean
itself but with an internal Weblogic op (is it trying to serialize the
EntityBeanContext as stated after the java.io.NotSerializableException
message?

Any help with this would be greatly appreciated as I have no clue how
this happened and I'm also unable to reproduce it (I'm also sure if I
managed to trigger it testing the application alone it will rise many
more times that could be admited if we move to production).

I would like to point also that currently until we have some more time
to fix it we are using "remote" entity bean, I mean even if we are alway
s calling them within the container they are not deployed with "local"
interfaces yet (although AFAIK Weblogic should avoid RMI calls on them
being co-located with the session beans).

Regards.

Ignacio.

P.S. here is the full stack dump

<12-09-2004 4:40' GMT> <Error> <app> <000000> <[thread 5
weblogic.kernel.Default]:Exception:
javax.transaction.TransactionRolledbackException at getXML
javax.transaction.TransactionRolledbackException: EJB Exception: :
java.io.NotSerializableException:
weblogic.ejb20.internal.EntityEJBContextImpl
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:78)
at weblogic.rmi.internal.ServerRequest.copy(ServerRequest.java:218)
at
weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:158)
at
weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:138)
at
app.data.production.ProductionBean_3toa0w_EOImpl_811_WLStub.EJB2DOM(Unknown
Source)
at app.data.general.GeneralBean.EJB2DOM(GeneralBean.java:1180)
at
app.data.module.ModuleBean_1v2h9c_EOImpl.EJB2DOM(ModuleBean_1v2h9c_EOImpl.java:3954)
at app.data.general.GeneralBean.EJB2DOM(GeneralBean.java:1180)
at app.data.general.GeneralBean.getXML(GeneralBean.java:1024)
at app.data.general.GeneralBean.getXML(GeneralBean.java:1002)
at
app.data.module.ModuleBean_nw294k_EOImpl.getXML(ModuleBean_nw294k_EOImpl.java:3138)
at app.biz.common.Publisher.performPublication(Publisher.java:1644)
at app.biz.common.Publisher.launchPublisher(Publisher.java:1580)
at app.biz.module.ModuleDAO.update(ModuleDAO.java)
at
app.biz.module.ModuleDAO_jcgreo_EOImpl.update(ModuleDAO_jcgreo_EOImpl.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at app.core.util.Proxy.execute(Proxy.java:583)
at app.core.servlet.BaseServlet.execute(BaseServlet.java:440)
at
app.user.servlet.common.BaseServlet.accessSessionBean(BaseServlet.java:279)
at
app.user.servlet.common.BaseServlet.buildResponse(BaseServlet.java:132)
at app.core.servlet.BaseServlet.doGet(BaseServlet.java:116)
at app.core.servlet.BaseServlet.doPost(BaseServlet.java:154)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6310)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3622)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
...

Slava Imeshev

2004-12-10 07:25:50 UTC

Permalink

Ignacio,

6.1 used pass-by-reference by default, so parameters to beans were
passed by reference.

It's very likely that you are getting this error because in 8.1 this default
was turned off. This causes serialization of parameters by default and
that's why your code that worked started failing - you just did not know
that you were passing non-serializable objects around.

To fix this you could either turn on the pass-by-reference explicitly and/or
find out where your code is passing non-serializable objects. This is a useful
exercise anyways.

Hope this helps.

Regards,

Slava Imeshev

Post by Ignacio G. Dupont
Hi,
We are currently in the process of moving from Weblogic 6.1 SP5 and
Toplink 3.6.3 to Weblogic 8.1 SP2 and Toplink 9.0.4 and during some test
I have seen a "scaring" stack trace. It seems that, for some reason, a
thing that "uses to work" failed with a very strange error. I tried to
reproduce it but without any success. Besides asking if anybody knows
what could have caused this error I would like to know what the "not
serializable" object is. Is it the EntityEJBContext?
<12-09-2004 4:40' GMT> <Error> <app> <000000> <[thread 5
javax.transaction.TransactionRolledbackException at getXML
weblogic.ejb20.internal.EntityEJBContextImpl
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:78)
at weblogic.rmi.internal.ServerRequest.copy(ServerRequest.java:218)
at
weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:158)
at
weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:138)
at
app.data.production.ProductionBean_3toa0w_EOImpl_811_WLStub.EJB2DOM(Unknown
Source)
In case it could share some light in the case I will explain a bit what
The general idea is that, given some data (managed with Toplink's 9.0.4
CMP) we take a XML "snapshot" of them (via a custom OBJ2XML class that
has been working for ages without any problem) and "publish" it via JMS
in order to perform asyncronous actions with it. I'm sure this is a,
more than usual, scenario for a lot of folks.
As it seems looking at the stack at some point during some internal
object serialization it fails and rollbacks all the process. The object
being serialized by our side only contains four attributes: a
java.math.BigDecimal for it's primary key, a java.util.Date for
timestamp locking and two simple java.lang.String's
Although I'm pretty sure the problem should not be with the entity bean
itself but with an internal Weblogic op (is it trying to serialize the
EntityBeanContext as stated after the java.io.NotSerializableException
message?
Any help with this would be greatly appreciated as I have no clue how
this happened and I'm also unable to reproduce it (I'm also sure if I
managed to trigger it testing the application alone it will rise many
more times that could be admited if we move to production).
I would like to point also that currently until we have some more time
to fix it we are using "remote" entity bean, I mean even if we are alway
s calling them within the container they are not deployed with "local"
interfaces yet (although AFAIK Weblogic should avoid RMI calls on them
being co-located with the session beans).
Regards.
Ignacio.
P.S. here is the full stack dump
<12-09-2004 4:40' GMT> <Error> <app> <000000> <[thread 5
javax.transaction.TransactionRolledbackException at getXML
weblogic.ejb20.internal.EntityEJBContextImpl
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:78)
at weblogic.rmi.internal.ServerRequest.copy(ServerRequest.java:218)
at
weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:158)
at
weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:138)
at
app.data.production.ProductionBean_3toa0w_EOImpl_811_WLStub.EJB2DOM(Unknown
Source)
at app.data.general.GeneralBean.EJB2DOM(GeneralBean.java:1180)
at
app.data.module.ModuleBean_1v2h9c_EOImpl.EJB2DOM(ModuleBean_1v2h9c_EOImpl.java:3954)
at app.data.general.GeneralBean.EJB2DOM(GeneralBean.java:1180)
at app.data.general.GeneralBean.getXML(GeneralBean.java:1024)
at app.data.general.GeneralBean.getXML(GeneralBean.java:1002)
at
app.data.module.ModuleBean_nw294k_EOImpl.getXML(ModuleBean_nw294k_EOImpl.java:3138)
at app.biz.common.Publisher.performPublication(Publisher.java:1644)
at app.biz.common.Publisher.launchPublisher(Publisher.java:1580)
at app.biz.module.ModuleDAO.update(ModuleDAO.java)
at
app.biz.module.ModuleDAO_jcgreo_EOImpl.update(ModuleDAO_jcgreo_EOImpl.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at app.core.util.Proxy.execute(Proxy.java:583)
at app.core.servlet.BaseServlet.execute(BaseServlet.java:440)
at
app.user.servlet.common.BaseServlet.accessSessionBean(BaseServlet.java:279)
at
app.user.servlet.common.BaseServlet.buildResponse(BaseServlet.java:132)
at app.core.servlet.BaseServlet.doGet(BaseServlet.java:116)
at app.core.servlet.BaseServlet.doPost(BaseServlet.java:154)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6310)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3622)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
...

Ignacio G. Dupont

2004-12-21 05:53:44 UTC

Permalink

Thanks for your response Slava, sorry for answering two weeks after but
these have been two mad weeks.

Post by Slava Imeshev
Ignacio,
6.1 used pass-by-reference by default, so parameters to beans were
passed by reference.

I readed something about it when we started to move to Weblogic 8.1

Post by Slava Imeshev
It's very likely that you are getting this error because in 8.1 this default
was turned off. This causes serialization of parameters by default and
that's why your code that worked started failing - you just did not know
that you were passing non-serializable objects around.

I checked our deployment descriptors and we where already using the
enable-call-by-reference with "true" in all our EJBs (we setted it for
performance reasons although it seems that we would have to set it
anyway as for the ref/value issue)

Post by Slava Imeshev
To fix this you could either turn on the pass-by-reference explicitly and/or
find out where your code is passing non-serializable objects. This is a useful
exercise anyways.

Once we move to Weblogic 8.1 I will try to check all the code in order
to be sure that all the objects passed to and from EJBs interface
methods are serializable.

Post by Slava Imeshev
Hope this helps.

I have not been able to reproduce the bug but I will like to ask you
another question.

Looking at the top of the stack trace:

javax.transaction.TransactionRolledbackException: EJB Exception: :
java.io.NotSerializableException:
weblogic.ejb20.internal.EntityEJBContextImpl
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)

it seems that the object that can not be serialized is the
"EntityEJBContextImpl" does it have any sense? Is there any way I can
"put" anything in that object that could prevent if from being serialized?

Post by Slava Imeshev
Regards,
Slava Imeshev

Thanks so much.

Regards.

Ignacio.

Slava Imeshev

2004-12-10 07:25:56 UTC

Permalink