During deserialization, memcached-session-manager's xml/javolution based serialization strategy just ignores fields that are no longer existing in new classes. Of course one needs to be careful with renaming fields, but I'd also like to have some mechanism to provide specific upgrade handlers.
Cheers, Martin On Fri, 2010-03-05 at 20:16 -0800, Douglas Ferguson wrote: > So as long as the serial I'd is the same the classlader won't care the > fields don't match? > > Douglas Ferguson > 512-293-7279 > Sent from my iPhone > > On Mar 5, 2010, at 3:37 PM, "Igor Vaynberg" <[email protected]> > wrote: > > > in the wicket code we override serial ids to 1, you should do the same > > in your code. > > > > -igor > > > > On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson > > <[email protected]> wrote: > >> I'm considering a 0 downtime deployment but am concerned with the > >> amount of state in the wicket session. > >> > >> This is the scenario that concerns me. > >> > >> 1) There are 2 tomcats running > >> 2) A change is made to a serializable object and the serial version > >> id is updated > >> 3) 1 tomcat instance is taken down for updating > >> 4) tomcat instance comes back up with new object and now tries to > >> update state from other tomcat and the wicket session has a > >> reference to the old version of the serializable. > >> > >> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote: > >> > >>> yes > >>> > >>> -igor > >>> > >>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson > >>> <[email protected]> wrote: > >>>> Has anybody had success with wicket using tomcat's session > >>>> replication? > >>>> > >>>> D/ > >>>> > >>>> --- > >>>> ------------------------------------------------------------------ > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >>> > >>> --- > >>> ------------------------------------------------------------------ > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Martin Grotzke http://www.javakaffee.de/blog/
signature.asc
Description: This is a digitally signed message part
