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

(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
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to