I worked on Hibernate core and the tools. Currently I work on making JBoss Tools and JBoss Developer Studio the tool to use for JBoss and Seam related technology.

Follow me on Twitter

Location: Mostly Switzerland, CET
Occupation: Core developer at JBoss, a division of Red Hat
My Links

Earlier today I saw a transaction question targeted for a completely different audience pop up as the first headline news item on a well known java news site. Besides giving me and my colleagues a good laugh about bugs and transactions it also touched upon one of the questions that have given me a couple of free beers in bar bets and been mind-boggling for students during trainings. The question relates to the following (simplified) code:

Connection con = DriverManager.getConnection(url, name, pwd);
Statement st = con.prepareStatement("delete VITAL_DATA");

Assuming that VITAL_DATA contains data before we execute this code, will it still contain those data after the call to con.close()?

Yes or No ?

The answer is: It depends!

If this code were executed against an Oracle database VITAL_DATA will no longer contain data since Oracle implicitly calls commit() if your connection has left over changes.

It is about here people starts arguing with me and say I'm crazy! No way that is possible, because all developers who believe in the goodness of transactions and its ACID properties would state that nothing should be committed to a database without an explicit call to commit() when not running in auto-commit mode - anything else would be a sin.

Well, I guess Oracle like to be sinful, and it is even documented.

/Page 3-14, Oracle9i JDBC Developers Guide and Reference/ contains the following text:

If auto-commit mode is disabled and you close the connection
without explicitly committing or rolling back your last changes,
then an implicit <code>COMMIT</code> operation is executed.

I heard from an Oracle tech-guy that this behavior is a left over from how the old OCI library worked - whether that is true or not I don't know; but it sure is a surprise for most developers I have shown this too (including my self the first time I bumped into this issue).

After discovering this a couple of years back I went to look in the JDBC spec to see who is to blame for this behavior.

The fun part is that I have not been able to find anything about the behavior of close() in JDBC besides the following text from the /JDBC 4.0/ spec:

When auto-commit is disabled, each transaction must be explicitly committed by
calling the Connection method commit or explicitly rolled back by calling the
Connection method rollback, respectively.

The javadoc for close() states:

Releases this Connection object's database and JDBC resources
immediately instead of waiting for them to be automatically released

From a naive ACID believing person I would say Oracle are wrong on this, but notice how the specification only mentions how the transaction behaves ? It does not explicitly state that close() is not allowed to commit the data, only that it should release resources (which it does!)

Thus from my perspective Oracle is walking on an edge here, but apparently without breaking the spec. Note that it might also occur on other databases, but it has never occurred for me on the other major databases I have worked with.

Lessons learned ? Always explicitly (or declaratively) commit or rollback your transactions!

19. Oct 2005, 20:04 CET, by Max Andersen

A new updated version of the Hibernate Tools ( project have been made available.

The tools are for both Eclipse and ANT, the ANT related docs are at

The biggest new feature is that you can now use your annotated classes in the query console (require JDK 5) and thus be able to prototype EJB3 queries.

We also added support for named parameters in the query console making it very easy to test existing queries from your application since you do not need to replace the parameters with inplace values.

See the screenshots and other noteworthy news at for more information.

As always feedback, ideas, contributions, patches, bug-reports are more than welcome by the usual means at and JIRA.

22. Aug 2005, 16:23 CET, by Max Andersen

A new updated version of the Hibernate Tools ( project have been made available.

The tools are for both Eclipse and ANT, the ANT related docs are at

The eclipse plugins is now compatible with WTP 0.7 and contains a bunch of new features and improvements.

My personal favorite at the moment, is the Dynamic Query Translator view which continously shows you the SQL, Hibernate will generate for the query you are typing in the HQL editor. Great for learning and tuning HQL queries - note that EJB3-QL works here too.

The HQL editor is also new and replaces the HQL view and introduces code formatting, syntax highlighting and code completion.

Furthermore we have a initial class diagram view as well as many other improvements to wizards, templates, and code generators. See the complete list with screenshots at class diagrams at for more information.

As always feedback, ideas, contributions, patches, bug-reports are more than welcome by the usual means at and JIRA.

09. Jun 2005, 04:29 CET, by Max Andersen

The new updated version of the Hibernate Tools ( project includes significant updates to the Eclipse editors, plugings, and wizards, as well as a unified and convenient Ant task for integration of the tools in your regular builds.

See for a visual mini-tour of the new features.

Ant task documentation is at

Recently I have been messing with adding custom class loading to Hibern8IDE, so it can load model and database driver classes at dynamically.

This allows us to run Hibern8IDE standalone instead of requiring users to run it from their actual project (which of course still is possible ;)

The 'trick' is as follows:

Thread thread = Thread.currentThread();
ClassLoader prevCl = thread.getContextClassLoader();
   try {
       List urls = ... // a list of paths/zips/jars for the classloader
       if(urls.size()>0) {
            URLClassLoader _newLoader = new URLClassLoader((URL[]) urls.toArray(new URL[0]), thread.getContextClassLoader());
        // convince DriverManager that you can use our specified driver!
        String driverClass = props.getProperty("hibernate.connection.driver_class");
        if(driverClass!=null) {
        try {
            Class driverClazz = ReflectHelper.classForName(driverClass);
            DriverManager.registerDriver(new FakeDelegatingDriver((Driver) driverClazz.newInstance()));
            } catch (... e1) {               
        configuration = new Configuration();
        configuration = configuration.setProperties(props);
        configuration = configuration.configure(configfile);
        Iterator hbms = mappings.iterator();
        while (hbms.hasNext()) {
            hbm = (File);
            configuration = configuration.addFile(hbm.toString());
         initialize(); // build sessionfactory etc.
        } catch (... e) {
       } finally {

The code does two things install Hibern8IDE custom classloader while loading the mappings and jdbc drivers PLUS install a FakeDelegatingDriver to convince the stupid java.sql.DriverManager that it is ok to load jdbc drivers from other places than the system classloader.

And this works!, but not when trying to Java Webstart enabling Hibern8IDE :(

It seems like Java Webstart is very strict about it's permission policy even though a <all-permission/> tag are in the JNLP file :(

The loading of model classes and drivers works smoothly, but as soon as the driver wants to connect to the database a security exception is throwing saying the application is not allowed to connect to a port on the database machine :(

So, for now Hibern8IDE is available in a standalone version, but unfortunately not via Java Webstart because of it's strictness!

Any bright ideas are welcome!

Showing 116 to 120 of 121 blog entries