JDBC Back to Basics: Part 1: Connecting

In this JDBC Basics series we'll go through the basic steps needed to get a knowledge of JDBC. Following this series we'll go through more advanced features of JDBC drivers, such as advanced security (Kerberos, etc...), performance tuning, etc.. For completeness, we'll show code examples for SQL Server, Oracle, DB2, Sybase, Informix, and MySQL as we know everyone in the world doesn't use the same database to store data.

The following posts are currently available in this series. This list will be updated as posts are written and will be contained at the top of each post in the series.

• Connecting (this post)

So, you want to write a Java application to get some data - you've come to the right place! Getting connected and fetching your data is easy using the JDBC Standard API that comes in the JDK. Let's jump right in by throwing out some code for connecting to SQL Server:

Class.forName("com.ddtek.jdbc.sqlserver.SQLServerDriver");

String url = "jdbc:datadirect:sqlserver://nc-pgm1:1433;databaseName=master";

Connection con = DriverManager.getConnection(url, "user1", "pass1");

There we go, easy enough. The first line which has the Class.forName is not necessary if you are using a driver that supports the JDBC 4.0 autoloading feature and Java SE 6. Therefore, you could remove this line altogether leaving you with 2 lines to connect to your SQL Server database. The URL is easy to deciper as well - he first part is which driver you want to use "jdbc:datadirect:sqlserver", followed by the server machine name (or IP address), port number, and database that you want to connect to. Lastly, you get the actual connection object passing in the url, user, and password. We'll go over Kerberos, Windows Auth and other security specifics in another post.

Ok, so what do you do after connecting? In my demo application, I like to print out some server information from the DatabaseMetaData object (helps to make sure I'm using what I think I am). Here's the code:

DatabaseMetaData dbmd = con.getMetaData();

System.out.println( "\nConnected with " + dbmd.getDriverName()

+ " " + dbmd.getDriverVersion()

+ " to " + dbmd.getDatabaseProductName()

+ " " + dbmd.getDatabaseProductVersion() + "\n");

This gives us a nice line that shows what you got connected to and with what driver version. Helps a ton when you're checking your output or have to send the output to someone else to look at.

Well, that's it for connecting - pretty straightforward. We'll continue next time with a different driver and start creating and working with tables!

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.

Can a SQL dog learn a new trick?

Ok, I admit it. I'm a relational guy. SQL is my language of choice - the old standby that does it all, why would I need more?!?

Another tool in my toolbox you say? Something for when SQL is not enough or I want to do more? The world isn't all rows and columns you say? Hmm.....I do like getting new tools. Perhaps I should learn some of this XML and XQuery hierarchal stuff - it could come in handy, no? Well where does an old SQL dog like me start?

First, you need some really smart friends who know this stuff already and are willing to share. Not someone who will share as an I-know-more-than-you guy, but someone who will share as a this-is-really-cool-technology-you-should-know guy. Otherwise you can start to head down a path and with nobody to help you sort it out you could get discouraged and quit - leaving you with no new tools. It just so happens that we have some guys here that know a thing or two about this XML and XQuery stuff and are willing to share and teach us SQL dogs some new tricks! wOOt!

Marc and Minollo are my friends that I'm talking about and they're starting a new series, "XQuery for the SQL Programmer" and I for one plan to follow it. Who knows, it may come in handy when we start to work with the SQLXML types in JDBC 4.0...........

See you there!

Virtualization and Data Connectivity

The Importance of Data Connectivity to Virtualization

Data center architects naturally seek to employ server virtualization to maximize the use of their hardware systems. However, one factor – often overlooked – carries real potential to undermine this goal. That factor is data connectivity. This article examines the importance of data connectivity in a virtualized environment, and the need to take an intelligent approach to data access to truly reap the benefits of your virtualization strategy.

Just recently, a really good friend of mine, Mike Johnson, was published in SOA Magazine reflecting on why Data Connectivity is so important in virtualized environments. As people move to consolidate server and IT infrastructure for various reasons it is good to know that someone is actually THINKING about how this will affect your performance for your most important applications - those that access business critical data. Take a quick read through the article to see how it can help save you time and money in your virtualization efforts.

Cloud Computing - is it a good idea?

We have all seen google app engine, amazon's web services, SQL Server Data Services (SSDS) from Microsoft, and others. The whole premise behind the movement is to make your IT infrastructure "rentable". I for one think that this is both a great idea and a bad one all at once. For instance, it makes coding mashups a breeze - on the other hand you have concerns about where your data is and if it is secure. The whole trend is something to keep an eye on as it is gaining in popularity.

What is Google App Engine?

What is Google App Engine? Here is a good description from their website:

Google App Engine makes it easy to build an application that runs reliably, even under heavy load and with large amounts of data. The environment includes the following features:

• dynamic web serving, with full support for common web technologies
• persistent storage with queries, sorting and transactions
• automatic scaling and load balancing
• APIs for authenticating users and sending email using Google Accounts
• a fully featured local development environment that simulates Google App Engine on your computer

I love it that Google eats their own dog food. These guys didn't invent a new "product" or come up with something to sell to the masses; they're using the same things that they built their company on! They have enough faith in their internal infrastructure that they're using it to allow us (the masses) to use these great products to build some really neat applications. Google is using the following components for their framework: Python application servers (more languages forthcoming), BigTable (Google's home grown database), and GFS (Google File System) data store services

As pointed out by TechCrunch here, this appears to be in response to Amazon's suite of web application enabling services: S3 (storage), EC2 (virtual servers), and SimpleDB (database). The difference is that Google is offering the whole stack instead of more loosely coupled services. Some SOA junkies would argue that this is not what they want, but I would beg to differ. First, it's Google doing what Google does well: offer everything seamlessly so that a developer can easily get one SDK, use one API, and one common environment to get an application written and deployed quickly. Basically, my money is on Google.

Now, if I were only one of the first 10,000 who got in on the Beta! Here's hoping to a quick run through the wait list! I'll probably download the SDK to play with anyway; I really want to see how Google's Query Language (GQL) stacks up against my favorite: SQL.

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

New NASA Website - nasascience.nasa.gov/ !

Ok, I know this is a data access blog, but I'm a geek. A real big uber geek and I love outer space. Therefore I was really excited to come across NASA's new website today! Here's the link:

http://nasascience.nasa.gov/

Some of my favorite things to look at are pictures from space. So, it's the weekend and I'll share the NASA multimedia image gallery site as well:

http://www.nasa.gov/multimedia/imagegallery/

These make great backgrounds and really mark you as a space cadet! Images of all the planets, black holes, everything looks great. I'm nearly done now, here is the link to the hubble site:

http://hubblesite.org/

Next time more on data access, I promise.

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.

Secure Mashups with SMash

I was doing some investigation into web service security, and ran across another nifty IBM tool: SMash. Smash (meaning secure mashups) is basically a technology designed to solve security problems when writing a mashup (a.k.a. situational application). These applications generally consume data/information from several different web services, and you need to ensure that there are measures in place to secure the data that they give to their calling applications.

Security is a concern by IT departments as mashups are typically written by non-IT staff and there is potential for leaked security. So, IBM wrote (and donated) SMash so that you can now authenticate your AJAX Web Services (Smash is javascript, so it's AJAX only at the moment). This is nifty as it appears as though you can secure your mashups by making sure that they can only access certain services you approve, or you can do other certificate based authentication.

The only issue I see with this is that it's non-standard. If the future is in services, seems like we should strive to come together and come up with a standards based way to do web service security (would WS-Security fit here?).

Well, since this is only javascript, I'm back to my research. For now, if you're interested in SMash, try out the code here (part of OpenAjax) or read more in this whitepaper from IBM.