HA requirements for Devs

What should Operations ask from Devs to consider when writing their code to
handle High Availability ?On Feb 12, 10:35 am, "Hassan" <has...@.hotmail.com> wrote:
> What should Operations ask from Devs to consider when writing their code t
o
> handle High Availability ?
Make sure that they dont hard code the server name or the IP ... The
code should pick up theses variables from an ini file... cause when
the primary server fails & you want it to point to the
secondary ..... all you need to do is to inform the users to change
the IP or the server name to start using the application ...|||If the applications are expected to gracefully handle a failover, developers
will need to include the appropriate retry code.
Hope this helps.
Dan Guzman
SQL Server MVP
"Hassan" <hassan@.hotmail.com> wrote in message
news:uq9upemTHHA.2256@.TK2MSFTNGP02.phx.gbl...
> What should Operations ask from Devs to consider when writing their code
> to handle High Availability ?
>
>|||"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:074A70E2-830C-48E2-93E5-330E8F24E84E@.microsoft.com...
> If the applications are expected to gracefully handle a failover,
> developers will need to include the appropriate retry code.
>
Most HA failover scenarios appear like a brief server outage to the
application. Retrying transactions and hiding the fact that an outage
occurred is sometimes an option, but it's difficult to code and test, and if
the outage is not _very_ brief this strategy will fail anyway. More
critical is making sure that the application resumes functioning correctly
after a brief server outage.
I would say it's acceptable to fail all the pending transactions and give
the users an error message. But when the users try again after the outage,
the application needs to work. For instance if the application holds open
connections to the database, it needs to close and re-open the connections
on certain errors. Especially important is ensuring that any server
applications or services resume gracefully, and don't require administrative
intervention.
David|||Thanks for adding this David. I agree that an error message during the is
failover is usually acceptable in the front-end and that it particularly
important that middle-tier service apps handle the brief failover outage
without manual intervention in order to maximize availability. Retrying
transactions can be tricky unless the app is architected with this in mind.
Hope this helps.
Dan Guzman
SQL Server MVP
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:OOJgzNrTHHA.600@.TK2MSFTNGP05.phx.gbl...
>
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:074A70E2-830C-48E2-93E5-330E8F24E84E@.microsoft.com...
>
> Most HA failover scenarios appear like a brief server outage to the
> application. Retrying transactions and hiding the fact that an outage
> occurred is sometimes an option, but it's difficult to code and test, and
> if the outage is not _very_ brief this strategy will fail anyway. More
> critical is making sure that the application resumes functioning correctly
> after a brief server outage.
> I would say it's acceptable to fail all the pending transactions and give
> the users an error message. But when the users try again after the
> outage, the application needs to work. For instance if the application
> holds open connections to the database, it needs to close and re-open the
> connections on certain errors. Especially important is ensuring that any
> server applications or services resume gracefully, and don't require
> administrative intervention.
> David