Monday, April 14, 2008

Studying the great works

An old colleague of mine, Joakim Sundén has written an excellent blog post on the importance of reading books (ok, from the point of view of a software developer). It's in Swedish but very nicely written and I can only agree with what he says. What baffles me is that so few developers in this industry read something (other than their own code). Few read articles, blogs or other people's code. And even fewer read books. I know, time's scarce. We all have families, hobbies, etc. Agreed. But if that's the case, then you should do it on your free time. If you are a person who is interested in a 9 to 5 job, I recommend that you have a career switch. Software development is not a field where you can just go to work. It requires a great deal of effort and agility to keep up with it.

We are in a profession where we are dead if we don't keep learning. To me being a software programmer is like being on a treadmill. You cannot afford to stand on a treadmill when it's on; you get thrown away. And that's exactly what happens the minute we quit learning in software development. Learning is something extremely important. And learning by taking a course, it's just one way of doing it. You could attend good conferences and symposiums definitely, but again all of those require budget, no doubt about it and we certainly must do that, but what's important is: that is something we're going to do a couple of times a year. That doesn't mean that we learn only a couple of times a year. So what do we do about learning? I want to talk about this as iterative and incremental learning. In other words we can not afford to learn something huge and large in just one day. We did this as students, cramming before the exam; we certainly shouldn't be doing that as professionals. - Venkat Subramaniam

One way to force ourselves to keep reading, learning is to do this within an organization. An example is to organize "brown bag sessions" where different people volunteer to be the lead in different discussions. You should be able to find at least one or two people that are interested in this kind of setup. Get them going, get management involved, arrange a few sessions and see what happens.

Just as we are interested in iterative software development we should be equally (or even more) interested in iterative learning. What did you learn today? Are you learning anything it at all? This should be a sign that tells all of us that it's time to get a new job :)

It's not easy but my personal goal is to become one of the mythical 5%

In my experience those in the 5% must struggle to get there, and struggle to stay there, and it's the process of continuous learning that makes the difference. - Bruce Eckel

We could compare software development with writing poetry. Mark Strand said that how good you are depends on how many poems you've written in your life. How do you get good at it? By writing poetry all the time. By reading relevant literature. By studying great poetry works.

Saturday, April 12, 2008

Tx isolation levels with JTA and Spring

I just "rediscovered" that JTA does not support custom isolation levels. I was using Spring's JtaTransactionManager together with @Transactional and setting custom isolation levels for different operations. The application was a legacy EJB2.x based application which had been migrated to Spring in order to simplify the deployment and eliminate the horrible realms of XML. But after eliminating the SLSBs lock problems in DB2 were observed. It turned out that some of the heaviest queries were not being run with the intended isolation value as defined in the annotations, just the default datasource level which is usually READ_COMMITTED. This level is the equivalent of "cursor stability" level in DB2.
The Cursor Stability (CS) isolation level is the default isolation level and locks any row on which the cursor is positioned during a unit of work
This was really not what was intended since it locks rows with a shared lock. Other transactions can still access the table for selects but holding the locks places a heavy load on the db. In this case what was desired was to have a READ_UNCOMMITTED isolation level for those completely read-only operations.

There are usually two ways to solve the problem of custom tx levels with JTA.
  • Define a datasource for each isolation level you intend to use in your application and then use IsolationLevelDataSourceRouter
  • Use a vendor-specific extension that wraps the JNDI datasource
It's typical to learn this the hard way so I'd like to recommend this article that shows how to specify custom isolation levels with Spring and JTA in detail.