This question is only good thru Wednesday, December 17th.

I have a large online transaction-based application that uses DB2 as
its database.  I want to put this online in a 2nd enterprise data
center, but I also want to be able to put transaction traffic in
either data center based on available load (load balancing).

The problem: a situation could occur where one of the data centers
goes down.  By this, I mean the application or the processing
capabilities.  I want to be able to "recover" a user's session at the
available data center with minimal disruption to their transaction
(none would be best).

What are some alternatives to "recovering" these transactions and
minimizing my risk?  One Prime Directive: transaction speed is
important (users are waiting).

How does this answer change if it were a SQL-Server based application?

Hi,

Weblogic Server allows you to do exactly what need. There is a concept
of "Clustering":

When a request comes in, one of the Servers from the cluster responds.
Any state changes that happen during the request processing are then
further propagated to the remaining servers in the cluster. In the
event that one (or more) Servers in the cluster fail, then the
remaining servers can pick where the previous ones' left off. All of
this is automatically managed by Weblogic server. Techniques can be
employed for this "state replication" and optimizing this process.
However, you are going to incur some performance overhead because of
the additional processing. Throwing more hardware, obviously, can
further reduce this.

Here is an excerpt from BEA's site about High Availability in the
context of clustering:
"High-Availability - A cluster uses the redundancy of multiple servers
to insulate clients from failures. The same service can be provided on
multiple servers in the cluster. If one server fails, another can take
over. The ability to fail-over from a failed server to a functioning
server increases the availability of the application to clients."

This is just not limited to Weblogic Server, other J2EE compliant
servers such as WebSphere employ similar Clustering mechanisms.

To answer your other question about SQL server, J2EE applications can
DB independent using JDBC. So, it doesn't matter what the underlying
Database Server is (of course I can't speak for the Systemic qualities
of the DB servers).

-Flash

HI,

I actually used to do alot of DB2 things for IBM as adatabase 
consultant. I have now TOTALLY converted to MySQL for all my web based
databased needs. It does a great job, is easy to get up to speed on
and yet SUPER powerful.

My first Google search turned up this company:
http://www.emicnetworks.com

Their software seems to do all the load balancing, disaster recovery,
etc things you need. Of course all this means you have to convert to a
MySQL solution. I did it, was WELL worth the conversion.

thanks, ed

I have a stupid solution for you. 

Write a front-end kind of software which will do very few things, that
is accept the input from user, pass it on to either 1st data center of
your or the 2nd. That will depend on where did you pass on the
previous request. Then, when your data center comes back with a
response, pass it on to the user terminal. Now, if one of data-centers
goes down (lets say center A), this front-end software will pass on
that failed request to B. That means you have to store the request in
the front-end until you get a successful response. You must be knowing
the expected response time (in my airlines applications it's 500 ms).
If you dont get the response within that time-frame, you can safely
assume that the center is down. This way, in case of data center
failure, there user will have to wait for little more than double the
time that he normally will. Your front-end software can prompt the
user to hang on, his request is being processed.

Trust me, writing this kind of s/w wont be re-inventing the wheel. It
will help you add 'n' no of things to this kind of in-house developed
s/w. Saves money, saves time, gives you freedom and sense of
ownership!