Is there a way to achieve non-stop applications, update the system?

Is there a way to achieve non-stop applications, update the system?

Old forum URL:

BeansLiu posted on Sunday, July 11, 2010

I was   writting a production management program  for a small business ,
However,  there is a problem bothering me,
Application has been formally applied, but users also need to continue the revision process.
If we modify the program must stop the on-site application,
and then publish the new procedures (clickonce), update and restart the middle of the application layer
. Because the production is 24 hours, so the user  is not very satisfactory for we stop the application when we update the application.
Is there a way to achieve non-stop applications, update the system?

The following is the structure of our application:

Client : .net winform ( use csla business object)

Application Server : .net Remoting (use csla business object)

Database Server : Sql Server 2005

ajj3085 replied on Sunday, July 11, 2010

Well, I think the only way you'll get away with this is if the client has failover servers.  Take one of the db and web servers off line, apply your updates.  Bring them back up.  Repeat for the other server, but of course in the middle of this process they'll have to close and restart the application.

IMO though, the client is not being reasonable.  There is no such thing as 100% uptime, and they should be realistically be scheduling in maintenance downtime.  I'm sure they don't run all of their machinery 100% of the time either; they take certain ones off line for planned (and probably unplanned) maintenance. 

rsbaker0 replied on Sunday, July 11, 2010

We found for minor updates using the web service portal that we could seamless refresh the web service while clients were running.  We could copy in the new .DLL's and recycle the application pool, and existing requests being serviced at the time we do this continue to finish up in the original process that was previously servicing the application pool, and no one was the wiser.

However, this works only if the client binaries are still compatible those on the server side of the data portal, so it doesn't work for major changes that require updates to the client also. So, it might work for you in some cases but not all.

BeansLiu replied on Tuesday, July 13, 2010

thanks a lot for all.

RockfordLhotka replied on Tuesday, July 13, 2010

This is theoretically posslble, but as people have pointed out it is not easy.

The same problems exist with any sort of service-based or n-tier model - the client and server need to update in sync, and if you can't have any downtime that's really tough.

It is pretty common in service-based systems to use a different URL for each version of the service, and you can do that with the data portal. So as you prepare to release version 2, set up a new data portal URL for version 2. Then, as each client restarts the app, you'd deploy (via clickonce?) version 2 of the client, with a new config file that points to the new version 2 data portal URL.

Of course that only works if your database is unchanged - so it is possible to have a window of time when some users are on v1 and some are on v2. If your v2 release requires database changes, then your challenge is greater, and it becomes extremely difficult to do a phased rollover with zero downtime...

Copyright (c) Marimer LLC