Bryan Lewis wrote / napísal(a):
> 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.
>
Thanks for hint. Yes, may be this is the only workaround we can do in
this situation: unbind DataContext from session before serialization
(HttpSessionActivationListener.sessionWillPassivate) and re-bind new one
after deserialization (HttpSessionActivationListener.sessionDidActivate).
> Disable Tomcat's session persistence.
>
We need session persistence to be able keep users authenticated and
authorized in case of upgrades/updates (24/7 availability).
>
>
> 2009/10/30 Miloš Bielik <
[hidden email]>
>
>
>> 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
>>
--
Milos Bielik
KYBEROS Group, Ltd
