assuming you have no breaking changes to your db schema having no downtime is relatively easy. while the process sounds involved it can be easily automated - ie you write it once and from then one deploys are easy.
* suppose you have two servers SA and SB in a load balancer pool PA * create a new load balancer pool PB and put into it a server running the upgraded version of your app SC * instruct your load balancer to only send new sessions to PB * wait until any server in pool PA is starved of its sessions and take it out of the pool, upgrade, and put it into pool PB. * once PA is empty drop it this is not so easy if you have breaking schema changes (or changes to other shared resources like webserivces) because once you upgrade the schema you cant have any old code accessing it. for such breaking changes you have to schedule a maintenance window. -igor On Tue, Nov 1, 2011 at 3:41 PM, taitai <[email protected]> wrote: > Hi guys, > I was wondering about the following standard scenario: > > - application v0.1 deployed to your favorite servlet container > - you want to deploy version v0.2 with minimal downtime and without losing > any session state (because it's a web shop application for example) > > Is there a convenient way to shut down a wicket application so that it saves > its complete state to e.g. the filesystem and the next wicket app that boots > up initially reads the state from those files? anyone else handling server > upgrades differently and in a better way? > > Thanks! > > > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Upgrading-of-Wicket-application-on-server-without-losing-state-tp3965762p3965762.html > Sent from the Users forum mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > 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]
