Tuning Hibernate and JPA @ JUG-Ka

After two sessions on client development, we are now turning our attention to the server side again. I'm very happy to welcome Michael Ploed from Senacor Technologies AG to talk about "Tuning Hibernate and JPA Applications" at the Java User Group Karlsruhe.

Michael will show us how to approach tuning of your Hibernate powered applications and which options exist, to increase your application's performance. Furthermore he will talk about Hibernate's second-level cache, which I'm looking forward to in particular. Finally, he'll demonstrate his tuning advices with a demo application.

This month we have a special prize in our monthly lottery: a free pass to the W-Jax conference, held this coming November in Munich. All you've got to do is send me an email and be present at the end of the session, when Michael will draw the winner.

The session takes place this Wednesday at University Karlsruhe, building 50.34 in the multimedia room 101, located in the basement. The talk starts at 7pm, a little earlier as usual.

We have more great talks coming up, the next couple of months. In order to get the latest updates, sign up for our Google Group or join us on Xing.

Spring DM Web Extender Problems

In my current project, I'm evaluating moving a large and very old code base to OSGi. Part of that is getting the the development team on board. I'm trying to point out, how much you can benefit from designing your application with OSGi in mind and the advantages you can have, running your application in an OSGi container.

I created some sample code with the help of the book "Pro Spring Dynamic Modules for Osgi(tm) Service Platforms" to highlight some of my OSGi presentation bulletpoints. One of the samples is running Tomcat inside of Equinox together with Spring Dynamic Modules. Although the sample is really simple and I sticked to the steps in the book precisely, Equinox spit out the following Exception:


After various failed attempts to google for a solution, I decided to consult the book again. Although, I thought I sticked to the steps closely, I missed an important point: start levels.

A start level is simply a non-negative integer value. The Framework has an ‘active start level’ that is used to decide which bundles can be started. Bundles themselves have an associated ‘bundle start level’ which is used to determine when a bundle is started. The bundles at a given start level will all have their start method completely executed before any bundles at a higher level are started. When booted, the Framework monotonically goes through each start level and starts relevant bundles (all the way until the active start level is met).
...
In the end, start levels are there to simply determine the start order of bundles.

I missed the fact that there is a start order in my Equinox run configuration. The bundles, which are in charge of bootstrapping Tomcat, need to be activated in special order, otherwise the previously mentioned Exception is raised. In particular the following bundles need to start in order:

...
org.springframework.osgi.catalina.osgi@3:start, \
org.springframework.osgi.catalina.start.osgi@3:start, \
org.springframework.bundle.osgi.web.extender@4:start, \ 
...

In "Pro Spring Dynamic Modules for Osgi" the config only orders the bundles and doesn't add any explicit start levels. However, I still ran into the same Exception from time to time, depending on other bundles I loaded. I put explicit start levels in my run configuration to solve those problems.

Git Svn

Last week I started working for my new company and like most of the IT businesses today, we are running subversion for Source Control Management (SCM). While we are still discussing, moving to a Distributed SCM (DSCM), I didn't want to lose the advantages of working with git. Remembering Samuel's talk at Java User Group Karlsruhe and with a hint from Ollie, I started using git-svn.

The git manual describes the svn capabilities as follows:

git svn is a simple conduit for changesets between Subversion and git. It provides a bidirectional flow of changes between a Subversion and a git repository.

git svn can track a standard Subversion repository....Once tracking a Subversion repository (with any of the above methods), the git repository can be updated from Subversion by the fetch command and Subversion updated from git by the dcommit command.

You can create a fully featured git repository from the trunk of a subversion repo with the following command:

git svn init -T https://svn.hostname.de/svn/projects/project/trunk

The git repository, that you just created is hooked to the trunk, passed with URL in the command. To get the HEAD, just run:

git svn fetch

Now you are ready to work with git, as if you had cloned a repo from GitHub. You can work with branches locally and commit your changes offline. When you want to share your work and push it back to subversion, you can use the following command:

git svn dcommit

You might ask yourself how to get the latest changes from your fellow developers? First, you should have no un-commited changes when you run:

git svn rebase

The reason for that, is this command is similar to svn update. It uses git-rebase instead of git-merge, in order to preserves linear history.

Those couple of commands got me started in no time and I didn't have to wait for a company-wide repository in order to have all the advantages that come with git.

No Improved Exception Handling

Last week Joe Darcy announced the Project Coin finalists. There will be 7 "improvements" to the Java Language for the upcoming JDK 7 release. Unfortunately, one of my favorite proposals "Improved Exception Handling" didn't make it. Don't worry, I promise this is not gonna be a rant post, rather my personal view on what I have to work with for the next couple of years.

I have to admit I was a little pissed at first, when I read, that "Improved Exception Handling" didn't get in. Especially, because it was one of the most requested proposals. However, after reading Joe's explanation on his blog, I do see, that it is not easy to prefer one proposal over the other:

Improved exception handling would be a fine change for the language, but it ventures near the type system and we do not estimate we have resources to fully develop the feature within JDK 7. I would like to see improved exception handling reconsidered in subsequent efforts to evolve the language.

At this point I would start the ranting on how Sun couldn't have enough resources, but I made a promise I wouldn't. There's another reason I shouldn't start ranting:

If there are frustrations waiting for Java language changes, I assure you there are also frustrations working on Java language changes. For example, I find it frustrating (and self-inconsistent) that people state "I don't have technical expertise in this area" while simultaneously expecting their preferences to be selected without any contribution on their part. [LINK]

I guess I am one of those frustrated people. I have no idea, if I lack the technical expertise, but what I do know is that I have enough technical expertise to judge that this is a PITA:

Statement stmt = null;
try {
   // do stuff that uses Statement instance
} catch (SQLException e) {
  // handle state
  log.error("Bad database", e);
} catch (NullPointerException e) {
  // handle state
  log.error("Bad parameter", e);
} catch (Exception e) {
  // handle state
  log.error("Bad luck", e);
} finally {
  try {
    stmt.close();
  } catch (Exception ex) {}
}

It is quite irritating, that this is what Java developers have to work with for the next couple of years. It is annoying, that there is no standard in the Java Language addressing this problem. There might be workarounds or some OpenJDK whatever branch with a prototype hacked into it, which exactly solves this problem. In my opinion, that's not a solution whatsoever.

In order to reduce programming errors, I think the Java Language must address this problem with a standard solution like "Improved Exception Handling".