JDBC at Cloud Expo

If your systems require constant accessibility, you know that application failover is an essential function for automatically and transparently redirecting requests to an alternate server in the case of a failure or downtime. Several options exist for ensuring high availability for your mission-critical applications. Those options may be hardware- or software-based, and may also vary considerably in terms of project or enterprise scope and in terms of cost and complexity. Chances are you're relying on one or more such options. But are you aware that the database driver software you use can make application failover much easier and cost-effective to implement, configure, and manage application failover?

High availability solutions are typically complicated and expensive to code. With an application relying on an Oracle data source platform, for example, the Transparent Application Failover (TAF) is what Oracle offers as a high availability strategy. This is certainly a robust solution; however, it must operate in conjunction with Oracle's Real Application Cluster (RAC) high availability environment. An existing application using a non-RAC replication solution cannot use TAF. Implementing Oracle's RAC environment is expensive, and to get an application to support TAF you'll be faced with writing a great deal of complicated, Oracle-specific code.

As an alternative option, you could implement, configure, and manage your application failover entirely through the JDBC software driver used to access the Oracle database. Drivers exist on the market that provide sophisticated failover capabilities such as replaying Select queries in progress and re-creating lost connections and sessions. This approach obviously offers advantages over a proprietary failover approach requiring database-specific application code and offering limited database-related flexibility going forward. But is a driver-based solution really up to the job?

Putting It to the Test
To demonstrate how you might implement a JDBC driver-based application failover, I prepared a use case example of the technology using a small Java application and a high-performance commercially available JDBC driver connecting to an Oracle database. In this demo, a company is writing a web application to browse through a number of golf courses. The country clubs that the company is working for expect a seamless experience for their users (i.e., the application is low tolerance). The data is replicated on two different servers and users get to browse through the course catalog (a page per course), and each page displays course information from the database. The developer wants to ensure that the application doesn't experience any errors or hiccups while a user is browsing the catalog. They want to ensure that, should the database connection to the primary server fail while fetching Course 5, users get Course 6 - rather than an error - when they hit the next button.

Having set up my primary database and replicating the data on my alternate database, I was ready to test failover. Since physically pulling the cable on or actually crashing the server running the primary database would have provoked undesirable responses from my co-workers, I employed a freely available packet analyzer (sniffer) utility called Snoop. It's designed to gather data about the wire-level traffic between the driver and server; however, it can also be used to simulate a database failure. Simply starting a Snoop program sitting between the application and primary sever and then killing the window running Snoop effectively terminates the connection by destroying the active socket. I set the snoop utility to listen to port 1521 on my local machine, connecting to my primary server (see Figure 1).

Next I set my connection URL such that the primary connection would go through the Snoop listener on my local machine, so that closing the Snoop window effectively simulates a connection failure. Listing 1 shows what my URL looked like. (Listings 1 - 4 can be downloaded here.)

Note that the primary server is to my local machine (nc-jdavis), which goes through Snoop to nc-lnx08 (in the Snoop window). In the URL, I added my failover options to indicate that nc-linux02 is the alternate server and I want the option for failoverMode. Setting failoverMode=select indicates to the driver that I want to failover seamlessly while going through the data - in other words, I'm telling it: "Make it look like I never got disconnected." In addition, I set a small performance option, failoverPreConnect, that causes the driver to connect to both the primary and alternate server during the first connect. This saves my application from incurring the cost of connecting during the failover process. It isn't much, but at runtime every bit counts. Let's take a look at the code that displays the results:

while (results.next()){
for (int i=1; i <= numCols ; i++) {
System.out.print("'" + results.getString(i) + "'\t");
}
}

You'll notice immediately that this looks like a standard loop iterating through the results and printing them to the screen. How do I know that I've failed over successfully? Easy - I check the warnings object, which will indicate when the failover occurs (see Listing 2).

Why not show something that indicates the failover? Because I don't want to have to change my code to add failover on the client side; I want it to work with my middleware out of the box (that is, with no changes necessary to client code). In addition, if the application were being developed using a packaged application framework (think Hibernate or Cognos), then you cannot change application code, which makes using this failover mechanism easy to incorporate in any application architecture.

Now I run the application. Notice that the output is formatted for easy reading. In Listing 3 you can see the successful connection information for the server as well as the rows of golf course information.

You can see that I've successfully connected to the primary server and fetched all the data. So the application works. But this is not the purpose of the demo: I want to see it fail. I set a breakpoint (or code in a pause such as System.in) on the line in my application containing the System.out.println() statement, then debugged the application and, when I hit the breakpoint, continued through it for the first six rows. The Snoop window showed my connection (see Figure 2).

Next, I simply closed the window, effectively terminating my socket connection with the database and hanging it there. Continuing again, I see that row seven has nevertheless printed out. The driver caught the "connection failed" exception, connected to the alternate database (nc-lnx02), replayed the connection parameters, refetched, validated the data, and positioned on the correct row. The only indicator that anything happened is in the warnings object, indicating a successful failover. This can be logged to the application logs, or used as a trigger to send an e-mail to the systems administrator for action. Listing 4 shows the output when the failover happened.

The Right Database Connectivity Middleware Is Key
Putting the logic of failover in an application is tedious and expensive. As the sample provided here demonstrates, letting the middleware handle the failover and repositioning logic can be a better strategy in terms of saving development time and costs and focusing on satisfying the needs of your users. However, this recommendation comes with a caveat: not all database connectivity drivers have this capability or, having it, can deliver it with sufficient robustness to serve as a viable failover strategy.

Database drivers provided by the database vendor, for instance - and often used by systems architects as the default choice - provide limited if any application failover support. In such cases failover typically involves dependencies on proprietary high availability environments such as Oracle RAC, Microsoft Cluster Server (MSCS), or DB2 High Availability Disaster Recovery (HADR). Where failover support is provided, it is only in drivers that are based on client-side libraries. For Java that means Type 2 architecture - which, in turn, means inferior runtime performance and increased deployment and maintenance costs.

If you're considering the simplicity and flexibility of application failover provided by data connectivity middleware, look for high-quality drivers that provide the following important benefits:

• No reliance on expensive and hard-to-implement server dependencies.
• Failover managed entirely by the driver, simplifying application code.
• Flexible and configurable failover options for various enterprise requirements.
• Standards-based approach, to provide consistency regardless of environment.
• Client load balancing, which works with failover to help distribute new connections so that no one server is overwhelmed with connection requests.

Making sure that application failover can handle connection failures in a standard way is key to ensuring the stability and uptime required by your customers. The database connectivity driver you implement should be an important part of your failover strategy. Some of them offer simple, cost-effective, yet sophisticated failover support to relational data sources, managed by the database driver versus adding costs in the application programs or implementing costly failover options provided by the database vendors. Obviously this is an offer you can't - or at least shouldn't - refuse to consider.