We had a similar problem. We had several variants of cayenne.xml and one
was chosen by our model code at run-time. However Tomcat by default
serializes sessions and recreates them at start-up, before our code gets a
chance to do its thing. We had an instance of our model stored in the
Visit, which of course is stored in the session, so Tomcat tried to recreate
it.
A couple of possible fixes:
If you have such an instance variable stored in the visit/session, make sure
it's marked transient.
Disable Tomcat's session persistence.
2009/10/30 Miloš Bielik <bieli..yberos.sk>
> Hi cayenne users
>
> We do not use default cayenne shared configuration approach. We use more
> cayenne FileConfiguration-s in our webapp development (have to merge
> more domains manually in the runtime: framework's with custom),
> cayenne.xml files are stored in different locations not in the classpath.
>
> Webapp works fine. But when web container (Tomcat) reloads or migrates
> sessions (eg. to another instance) HttpSessions are
> serialized/deserialized. At this moment our *sesion scoped* DataContext
> is trying to wake up from deserialization, unfortunatelly it tries to
> init default shared configuration. Of course, exception is thrown.
>
> How can we make DataContext instances re-initialize correctly and bind
> to our custom configuration?
>
> --
> Milos White Bielik
>
>
>
This archive was generated by hypermail 2.0.0 : Fri Oct 30 2009 - 08:59:32 EDT