RE: Upgrading from 1.3.8 to 1.4.5 - (de-)serializing errors

[Jonas Lundberg]

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

-----Original Message-----
From: Jonas Lundberg [mailto:[EMAIL PROTECTED]]
Sent: den 21 maj 2001 17:58
To: Orion-Interest
Subject: Upgrading from 1.3.8 to 1.4.5 - (de-)serializing errors

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
.....................................................