Hot off the presses JDBC 4.0 release - and why you care!

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.

Programming for multi-core performance - in Java?

Performance is a huge concern when writing any Java code, especially since many still do not realize the benefits of coding to a hotspot vm and believe Java to be a "slower" language than something like C/C++. As someone with a hardware background, I frequently hear that faster computers are the answer. To an extent, they are correct. To this end, processor architects have been putting more processing power in our beloved machines by adding nifty new technology like hyper-threading, cores, and increasing the on-die caches in recent years. All this is great; however, we can tap this power to a greater extent if we software guys have ways to program closer to this type of hardware.

Back in college, we had a homework assignment to finish adding the hardware in a CPU necessary for the jump assembly command. We did our diagrams and loaded it all into our CAD tool. After we had the full layout of the processor in memory (first time of course!) we had to do some testing. So, we used VERILOG for the first time, and doing so was quite an experience. We were rudely introduced to a programming style that was purely parallel; we were basically coding electrical impulses through tiny wires. In any case, it is a very different feel than doing your standard sequential programming (Java/C/C++/C#)and it is more than a little difficult to get accustomed to. The first few times we tried it we encountered many race-through issues and problems making sure all the code paths lined up. It was quite a learning experience indeed.

For the past few years, there have been many discussions on how to best program threads for this environment in the C/C++ languages. Intel has many good documents on the OpenMP API (here's a good one), along with some interesting comparisons (and arguments) to using PThreads as well. However, what about us Java guys, and could there be a better way than straight-up thread programming?

As I said before, parallel programming is interesting, but it's extremely difficult to master. In addition, we must take into account scalability - programming for 2 cores may be different than programming for 100 cores (thinking ahead, of course). Is it unreasonable for us to find a way to abstract the threading and split up work when the JIT compiling takes place? I hope not, because doing so would be really nifty, especially since the Jedi Thread Masters among us are few and far between.

Enter JSR-166 and JSR-166y fork/join framework! According to Doug Lea, the framework is "a style of parallel programming in which problems are solved by (recursively) splitting them into subtasks that are solved in parallel, waiting for them to complete, and then composing results." Here is his pseudo code to demonstrate:

Result solve(Problem problem) {
if (problem is small)
    directly solve problem
else {
    split problem into independent parts
    fork new subtasks to solve each part
    join all subtasks
    compose result from subresults
}
}

I think this is a really big step in the right direction for Java, but is not quite the holy grail of multi-thread abstraction for the masses. I'm still researching this framework, but at first glance, the framework appears to allow the application to be coded such that depending on the size of the task/algorithm, one can easily fork/spawn a separate subtask that is computed in parallel (waiting for them all to complete of course), then joining them back together. This has enormous potential in my opinion!

I'm going to continue my research and will post my thoughts here. In the meantime, take a look at Doug Lea's paper, "A Java Fork/Join Framework" as well as some of the existing JSR-166 collections in Java SE 6: Deque, BlockingDeque, NavigableSet,NavigableMap, ConcurrentNavigableMap, ArrayDeque, LinkedBlockingDeque, ConcurrentSkipListSet,ConcurrentSkipListMap, TreeMap.

Resources:

A Java Fork/Join Framework by Doug Lea

Concurrency Interest Site

JSR-166 Site

JDBC 4.1 BoF at JavaOne 2008!

Just a quick note to say that the JDBC Expert Group (of which I'm unashamedly a part) will be having a Birds of a Feather session on Tuesday night at this year's JavaOne conference! Please drop by and let us know if you have any input on what we're considering and working on for the upcoming JDBC 4.1 features list! Below is the description of the BoF:

This BOF session brings together members of the JDBC Expert Group and other people interested in finding out more about the features being targeted for the JDBC 4.1 specification and its progress to date to discuss priorities and directions for work within the context of the JSR.

The JDBC 4.1 technology is being targeted for the Java Platform, Standard Edition 7 (Java SE 7 Platform).

I don't want to spoil anything for Lance, but we've got some really nice things to add to the spec for the next version to make JDBC Data Access better than ever.