Well, IF you're really keen on non-intrusive upgrades you can always put
in a version in the db and make the code handle both old & new version.
But that's admittedly a lot of extra work. Downtime is way easier when
schemas change and for web-apps the downtime should be easy to keep short.
Regards
Robert
On 11/02/2011 12:38 AM, Igor Vaynberg wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
