Sonar “Close Connection” warning workaround.

When you use Spring and Ibatis and SQLTemplates, you could have code in your project which looks somewhat like this:

Connection connection = DataSourceUtils.getConnection(getDataSource());
...<do connection stuff here>...
DataSourceUtils.releaseConnection(connection, getDataSource());

Sonar will report that you did not close the connection, while in fact, Spring did that for you. You can not just add a “connection.close()” to the code because the whole point of calling “releaseConnection()” is to have Spring handle all the smart stuff on committing, closing, and returning the connection to the pool if needed.

In our company, not closing the connection is a major blocking violation (and it should be). But in this case, there is no way to make the Jedi wave to Sonar, telling it that “this code will do just fine”. So I added the following trick, albeit a bit dirty:

if (connection.isClosed()){
   // This code is only here to keep Sonar from
   // warning us that the connection is not
   // closed. Please note: Do not just close an
   // unclosed connection, Spring should handle
   // connection closing and returning to the pool.
   connection.close();
}

Use it to your advantage, but use this responsibly. If you see any problems in my solution, or if there is a better way to do this I’d be happy to hear about it.

Transactions and Isolation levels

At work, we have two applications which connect to the same database. For all kinds of business reasons, we need to make sure that only one of the applications accesses certain data at the same time. To do this, we use a row in a table as a semaphore.

While working on the locking mechanism, we had a closer look at the Transaction Management and the Isolation Levels we were using. There is a lot of good documentation on Transaction and Isolation, but it tends to be over complete, elaborate and therefore hard to read. I’ll try to share our insights with you in a slightly more digestable form (I hope).

Starting Java app from Applescript

Suppose you have a Java Swing application which you can start by typing the following on the command line:

java -jar myTerrificSwingApp.jar

If you want to make that application start from the Finder in OSX, there are a lot of options which range from ugly to convoluted. If you need a quick fix, here’s how to do it.

Javascript Window Shake

This evening I came accross the window.moveBy() JavaScript function and thought it would be cool to shake the browser window when a user fails to log in. It turns out that I was not the only one thinking this, but none of the examples worked for me. Some had no proper delays, others only worked from the page header, and some were plain unreadable.

I’m no Javascript guru, but I hacked this together which is working pretty nicely. It is in fact almost undistinguishable from the Apple login window shake at a login failure:

<script type="text/javascript">
if (window.moveBy) {
	delay = 70;
	shakes = 3;
	window.moveBy(-10, 0);
	for (j = shakes; j > 0; j--) {
		setTimeout( "window.moveBy(20, 0)", j*delay );
		setTimeout( "window.moveBy(-20, 0)",
					j*delay+(delay/2));
	}
	setTimeout( "window.moveBy(10, 0)", (shakes+1)*delay );
}
</script>

In my case, I surrounded this code with a Tapestry @Conditional and made it into a reusable Tapestry component so that I can make any window shake as soon as it contains an error.

The code will work anywhere on your page, but I advise you to put it at the bottom of the HTML. This will make sure that the content is shown in the browser before you shake it.

It’s visually much stronger than just adding an errortext to the page. If people log in a couple of times a day, they don’t even notice extra text on the screen. This will “shake” them awake

Have fun!

Care vs Careless

 

 

It’s frightening to realize how close to the truth Eric Burke is.