Comprehensive solution for crafting and managing sophisticated digital experiences
Build engaging websites with intuitive web content management
Leverage a complete UI toolbox for web, mobile and desktop development
Build, protect and deploy apps across any platform and mobile device
Build mobile apps for iOS, Android and Windows Phone
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate UI, load and performance testing for web, desktop and mobile
Host, deploy and scale Node.js, Java and .NET Core apps on premise or in the cloud
Optimize data integration with high-performance connectivity
Automate decision processes with a no-code business rules engine
Transform your businesses in order to survive in a completely digitized and connected world driven by software innovation.
Globally scale websites with innovative content management and infrastructure approaches
Content-focused web and mobile solution for empowering marketers
Faster, tailored mobile experiences for any device and data source
UX and app modernization to powerfully navigate today's digital landscape
Fuel agility with ever-ready applications, built in the cloud
What's the big deal you say? Well, we now have the best client-side application failover of any JDBC drivers. It makes Oracle TAF look like a toy. To start with, we do not require that you use an expensive server-side technology like Oracle RAC, DB2 HADR, or Microsoft Clustering. Although not required, the drivers support these technologies but we just don't feel like you should have to shell out all the moola if your mirroring system has been working for you - we need to work with what you've got. Additionally, we use standard SQL states and error codes - none of the "proprietary" error code issues you get when working with other failover technologies. Have you ever tried to just use failover with an existing application? If you've got to change hundreds of lines of code to get proprietary error codes checked then it's just a bad failover implementation in my opinion. Ok, enough of the "ours is the best" let's just explain how it works.
To use our failover, all you need to do is specify the alternate server(s) by using the alternateServers connect option. Then, specify the level of failover you'd like by setting the failoverMode connection option. You can set connect, extended, or select failover modes.
Connect failover is the "Let's make sure we get connected" mode. This will attempt a connection to the primary server, and if that fails, the first alternate server, and so on until it gets connected to something. Number of retries and additional connection attempts are all configurable using additional options. After the initial connection, the driver doesn't do anything to make sure you stay connected. That leads us to the next failoverMode.
Extended failover is the "Let's make sure we stay connected" mode. This mode handles the case where you're connected and something bad happens (node goes down, power failure at station 1, etc..) that kills the connection to the server. When extended failover is set, the driver catches the connection failure error and attempts a connection to the alternate server (we'll iterate through the list if we don't get connected to the first one). Once connected, the driver ensures that all the connection options are replayed, and all the statements are re-prepared, but not re-executed. In essence, this mode of failover makes it look as if you had a transaction failure instead of a connection failure - useful if your application is coded to handle transaction failures and not connection failures. But what if you want to replay everything, including selects? Let's take a look behind door number 3....
Select failover is the "Let's make it look like we never got disconnected" mode! This is the most complex of the three modes as it not only reconnects and replay/reprepare, but it also repositions you in your resultSet! Yes folks, a little Java magic for us all - just in time for Christmas! How does it work? Well, once the driver reconnects and replays / reprepares your statements, we will re-execute the selects (not the inserts - that's dangerous) and we check the rows returned and put you back on the same row as you were before. From the application perspective, resultSet.next() or resultSet.getString(5) returns as if nothing happened. Give it a try and see which one works best for your environment.
That's not all we did in our 4.0 release either. We now support the full JDBC 4.0 specification - and in a way that no other JDBC drivers do: one jarFile will work for all versions of the JDK that we support. No seperate jar file if you want to use a Java SE 6 and a seperate jar file if you want to use a Java SE 5 environment! The driver intelligently figures out the correct class interfaces to load, saving you configuration time in the process. Just plug in and go.
That's it for the announcement, I'll be blogging about the new features more next week - stay tuned for SQLXML examples, NCHAR explanations, and more ease of use features. We'll also go over some of the new Oracle 11 and DB2 v9.5 features.
The new Connect for JDBC 4.0 release is hot off the presses and available for download here.
As Senior Director of Research & Development, Jesse is responsible for the daily operations, product development initiatives and forward looking research for Progress DataDirect. Jesse has spent nearly 20 years creating enterprise data products and has served as an expert on several industry standards including JDBC, J2EE, DRDA and OData. Jesse holds a bachelor of science degree in Computer Engineering from North Carolina State university.
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.