Think Hibernate Means You Don’t Have to Worry about Your JDBC Driver? Think Again.

It’s interesting to note how often we hear someone say, “Well, I’m using Hibernate, so I don’t really care about JDBC.” In fact, many think they don’t even need a JDBC driver at all, not realizing that the driver operates under Hibernate. Hibernate has a lot of benefits – it is flexible, and does a fantastic job of level-setting the different kinds of drivers that you put under it.  You can tell it what driver to use or which database back-end it’s plugging into. The problem is that most drivers out there simply cannot be configured once they’re already deployed in a Hibernate environment.

Issues can really start to crop up when you don’t consider your JDBC driver early in the process, and chances are you are going to pay for it later (which is always more expensive!). Many vendor drivers are coded in a way that extends the JDBC API, including additional methods that they think should be included in the spec – knowing full well if you use them then you’ll not be able to move to a different database or driver without code changes. This can in no way be seen as a clean spec implementation.

When applications are coded to a modified, vendor specific spec, it becomes really hard to move to other environments and retain functionality. When used under a framework like Hibernate, which has only been coded to the original spec, you’re going to find yourself losing some functionality unless you’re willing to actually change Hibernate code itself, taking away time you could be using to make your product better!

Here at Progress DataDirect, we get really excited about the idea of configuring your drivers without having to worry about the framework it’s under. It’s something we call codeless configuration, where we help customers configure their driver without the need to change any code! This makes it much easier to tweak because you can make modifications at the connect option level – and not at the API level. This means that anyone can do it – and without the effort needed for a more involved API level modification.

For a practical example, imagine an IT worker at a hospital, which has many applications written on Hibernate with a JDBC driver underneath. Imagine this guy (or gal!) deploys the application and runs into an issue – let’s say he finds a memory leak, or the application is using too much memory. He then goes looking into the documentation for the driver and eventually finds that the driver he’s using has a way to tweak the amount of memory his application is using – sweet! However, the only way to tweak the memory usage for that Statement is to cast to a vendor specific object and call a proprietary method. Hmm….now his options are to live with the memory problem or modify his Hibernate instance (code change, recompile Hibernate, etc.) to use the cast and proprietary method. This sucks!

Let’s imagine that the frustration level was too much and he instead went a-Googlin’. He wants to configure the driver without touching code; a simple connection string change would be nice. Asking the great Google to show him a way to do ‘codeless configuration’ on a JDBC driver turns up some interesting results. He finds that there is a driver that allows him to configure the memory usage for his Statement using a connect option, and before lunch his memory issues are now a distant memory. Lucky for you, you don’t have to consult Google to find a driver that can do this, because we offer one you can download and try today. :)

?

I think it’s really cool that we have a way to help developers get the most bang for their buck with their data access choices. Codeless Configuration is one of those game changing ideas that benefits everyone and frees us to code to a standard the way it was meant to be – without worrying about whether we’re locking ourselves into a specific solution and instead being confident that we can reuse our code when we need to and still have the flexibility to tune based on our application needs.