On Sep 4, 2007, at 10:27 AM, Daniel Lopez wrote:

> Hi,
> First thing I did was to clean up all the deployment directory, making
> sure the WEB-INF/sessions directory was removed, and session lifetime
> is 30min, so they shouldn't have survived all the weekend in any case
> :).
> I tried with Resin 3.1.2, just in case, and the result was the same. I
> downloaded Resin source and built the resin.jar from scratch adding
> some debugging info and I ended up at the readObject() call. So it
> seems for some weird reason that de-serialising that object inside a
> Session fails. However, I tested the serialise/de-serialise process
> using the same JVM on the class giving the errors and I had no problem
> doing it. Weird.

Can you try changing the serialization-type to hessian:

<session-config serialization-type="hessian"/>

I'm not sure that it will change anything, but it might give a  
different error message that might help.

> Is the srun.db file in some kind of format one can easily grasp?

Not really.  It's a virtual filesystem/database-row structure.  There  
are inodes and fragments, and indirect blocks and all sorts of nasty  

(It does support a JDBC API, though.  So if the hessian change  
doesn't give enough information you could copy it to another  
directory,  and launch a jdbc driver  
com.caucho.db.jdbc.ConnectionPoolDataSourceImpl with <path>foo</ 
path>.  I wouldn't recommend it, but it's possible.)

-- Scott

> I
> might try to deserialise an instance of such a file to see what's
> going on. At least I should be able to determine if the problem
> happens when writing or when reading the object.
> Thanks!
> D.
> S'està citant Scott Ferguson <[EMAIL PROTECTED]>:
>> On Sep 3, 2007, at 1:46 AM, Daniel López wrote:
>>> Hi,
>>> I have some objects in a library that I'm using that are usually
>>> stored
>>> in the session. Up to now, everything worked fine but recently I
>>> decided
>>> to do some refactoring to update the version to Java 5 and I
>>> "basically"
>>> changed a member from being a Hashtable to being a Map (HashMap as
>>> implementation).
>> Is it possible that the old persistent data is still based on the  
>> pre-
>> refactoring information, e.g. if you had a very long session live  
>> time?
>> -- Scott
> S'està citant Jay Ballinger <[EMAIL PROTECTED]>:
>> Are you trying to use session objects that are from the past? If  
>> these
>> objects were serialized before your change, they will probably be
>> incompatible with your new change. You'll need to clean house of the
>> serialized artifacts first.
>> + jay
> ----------------------------------------------------------------
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest

resin-interest mailing list

Reply via email to