----- Original Message -----
Sent: Tuesday, May 22, 2001 12:32
PM
Subject: RE: Upgrading from 1.3.8 to
1.4.5 - (de-)serializing errors
We solved
these problems today. It came out that the class that failed was the ResultSet
(but with obfuscated name) of the database driver. This class was not
serializable, and the upgrade from 1.3.8 to 1.4.5 probably separated our beans
into separate VMs, thus requiring Orion to serialize the ResultSet object.
To solve
this we wrote our own container for the result data (using Vectors containing
Hashtables).
/Jonas
We have
encountered some serious problems when upgrading from Orion 1.3.8 to 1.4.5.
The
problems occurs when our business layer is about to return data to the
presentation layer. The data is fetched in the datalayer via a callable
statement. The callable statement and the connection is closed in the
data-layer-EJB.
The
business-layer-EJB removes the data-layer-EJB after it has retrieved a
ResultSet from it. The business-data-layer then returns data extracted from
the ResultSet or sometimes just data from the ResultSet.
It still
works perfectly fine to use methods that submit data but not returns
anything from the data layer. But after the upgrade, the methods that return
data is failing.
The
reported error is as following:
[Mon May
21 12:41:54 GMT+02:00 2001]: Error in getPoll, BlPollBean.
java.rmi.Rem
oteException: Error (de-)serializing object: com.inet.tds.d;
nested exception is
:
java.io.NotSerializableException:
com.inet.tds.d
com.evermind.server.rmi.OrionRemoteException:
javax.ejb.EJBException
at
com.evermind.server.ejb.EJBUtils.getUserException(JAX)
at
BlPoll_StatelessSessionBeanWrapper12.getPoll(BlPoll_StatelessSessionB
eanWrapper12.java:446)
at
__jspPage5_polltest_poll_statistics_jsp._jspService(__jspPage5_pollte
st_poll_statistics_jsp.java:75)
at
com.orionserver.http.OrionHttpJspPage.service(JAX)
at
com.evermind.server.http.HttpApplication.xj(JAX)
at
com.evermind.server.http.JSPServlet.service(JAX)
at
com.evermind.server.http.d3.sw(JAX)
at
com.evermind.server.http.d3.su(JAX)
at
com.evermind.server.http.ef.s1(JAX)
at
com.evermind.server.http.ef.do(JAX)
at com.evermind.util.f.run(JAX)
It seems
like Orion tries to de-serialize com.inet.tds.d, but why? On the same
installation other implementations run using the same com.inet.tds
provider.
I
saw some problems on this list earlier describing these kind of problems,
but that was regarding fields that needed to be "transient". We have no such
"stateful fields", so we don't think that has something to do with these
problems that we encounter.
Anyone got a
clue?
/Jonas
.................................................�
Jonas Lundberg,
M.Sc.
Systems
Architect
Framfab Sverige
AB
Holl�ndargatan 20 (Box 5494)
SE-114 84 Stockholm
SWEDEN
mailto:[EMAIL PROTECTED]
Direct:
+46 8 410 004 59
Mobile: +46 70 995 49 59
Phone: +46 8 41 00 10
00
Fax: +46 8 410 002 50
Internet: www.framfab.se
.....................................................
