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 <[email protected]> > > >> 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
