Xebia Blog

One of the most heard complaints about Spring projects is the seemingly unavoidable configuration-hell that silently creeps in every bigger project after some time.

Singleton injection is a simple practice that can significantly reduce configuration and corresponding injection code. Besides that, it provides possibilities you might not have been aware of enabling you to get most out of Spring. In this blog you will learn which advantages Singleton injection provides. It illustrates how to implement it and specifies clear guidelines in which circumstances it is applied best.

Where applicable, Singleton injection can be an elegant solution that provides significant code and configuration simplification.

(more...)

Filed under: Java, Spring
3 Comments

For those people that saw my talk at J-Fall on 11 October 2006 and came here looking for more on the Top 10 Enterprise Java Performance Problems: it's coming!

I've already thought of a name: EJAPP - Enterprise Java Application Performance Project.

And I got a wiki at JOCE. The wiki is still empty, but I'll put the slides up there very soon. First in Dutch of course, but I'll translate them into English quickly after that and then I'll start making it into a proper Wiki instead of a slide repository.

In the meantime if you've got any good ideas on this, please post them here or mail me.

Regards, Vincent.

October 22, 2006 Update: the English translation of the presentation is available on the EJAPP site.

Filed under: Java, Performance
1 Comment

In quite a few coding standards I have seen a guideline saying all local variables must be initialized at declaration. No doubt the authors were copying from, erm, inspired by Sun's Java coding standard guideline 6.2 which says

Try to initialize local variables where they're declared. The only reason not to initialize a variable where it's declared is if the initial value depends on some computation occurring first.

Sounds all nice and dandy. What could be wrong with that?

Well, the result of this guideline is that a lot of developers who can't think of a useful value to initialize their variable with decide to initialize it with null instead of leaving it unitialized. This has the nasty property of not catching a lot of NullPointerExceptions that would have resulted in a compile time error along the lines of "The local variable x may not have been initialized" if the developer had just left that variable uninitialized instead.

It's a pity Sun recommends such silly things which were probably inspired by the C/C++ era when uninitialized variables would contain garbage. Then again, Core J2EE Patterns is still in print while nearly all of the patterns described in it are either outdated or wholly inappropiate by now. But more on that later...

Filed under: Java
3 Comments

For our project we use Hibernate. The application we are building reads work items from the database, processes them (validation) and writes the results back to the database; a typical data processing application. Optimally the process would be streaming, a gigantic select would be used to fetch millions of rows and process each row in a transaction (The processing of a row results in several DML statements). Now there are technical obstacles to implementing the application in this fashion. The RDBMS should be able to process millions of short transactions, while keeping the long transaction that reads the rows alive. Oracle cannot handle this, due to its read consistency functionality. After quite some time a ORA-01555: snapshot too old (rollback segment too small) will inevitably crash the long running transaction. Our implementation divides the gigantic select in smaller chunks, to prevent the "snapshots" from getting "too old".

Pfff, the first obstacle was out of the way. Next problem: Hibernate. We chose Hibernate as our ORM solution, because... because... we were all already familiar with it. Which is the lamest excuse in the world and will mostly lead to solving the wrong problem with the wrong tool. The problem with Hibernate in this situation is at the same time one of its main features. To support transactional write-behind Hibernate keeps track of all objects loaded in its Session. During the batch processing all work items get loaded in the session. The memory associated with this isn't the biggest problem. Whenever a Session is flushed, Hibernate will inspect each associated object to look for changes and write these to the database. If the session gets big, flushing it will take more and more time, even if there are no changes, as is the case with this long read transaction. The solution for this is to evict the objects from the session as soon as possible. Since we read the objects from a ScrollableResults each result is loaded separately. We wrap this results object in an EvictingIterator that will evict every work item from the session. When using this approach, one has to be very careful to evict all objects, also the objects that are loaded by cascading. Luckily, 'evict' is a cascade option of Hibernate, so in the mapping files specify cascade='evict' on all associations that are loaded and... presto!

Now let's take a step back: what problem have we solved here? Using Hibernate to do the gigantic select to fetch the objects from the database has not helped us a single bit. Quite the opposite; we have to work around Hibernate's Session to make it work! This is exactly how a Golden Hammer can lead you astray. Instead of solving your problems, it leads to more problems that are solution specific. So after making it all work with Hibernate, we decided to invest some time in trying to find another solution. Our first attempt was Ibatis.

We decided to invest a week on the Ibatis PoC. We ended up spending most of the time cleaning up our configuration, code and tests, but finally we got to the actual Ibatis code. This is what we found:

(more...)

Filed under: Hibernate, Java
9 Comments

Often JEE applications contain property files with environment specific information. Because deployment should be automated, you need some way of dealing with these property files. Basically you have three options:

1. Put a default property file in the ear and edit it after deploying it to the server. This means you have to do some scripting with Perl or some other language.
2. Choose the property file to put in the ear before you deploy. If you choose this option, you need to know the correct property values in advance. Further more, you need to tell maven or ant which property file to deploy by setting some sort of environment flag
3. Store the property file on the system classpath instead of in the ear. This has the disadvantage that you need to restart the server every time you want to change something in the file.

Usually property files are application specific, so I prefer either of the first two options. The other day, however, I got a call from someone who needed to store the property file on the servers' classpath.
Of course(!?) every application server is different. In IBM Websphere you put property files in the [WAS_HOME]/appserver/properties directory and configure the server, so it knows where to find the property file.
(NB: for those of you who have been looking for this feature: it is hidden under Application Servers > [server] > Process Definition > Java Virtual Machine - Custom Properties) The Oracle application server doesn't have a folder like that, nor does it have any options to specify property file locations. So where do you put property files if you want to put them on the system classpath? The Oracle container (OC4J) has two possible candidates for this property file:

• the applib directory
• shared-lib directory.

I decided to do a little test: I created a test application that displays the values in a property file. I used the standalone OC4J(10.1.3) for this test, but it works the same way in the Oracle Application Server 10g. First I tried the applib directory. I deployed the application to the OC4J, stopped the server and copied the property file into the [ORACLE_HOME]/j2ee/home/applib directory. Then I restarted OC4J. The web application displayed the values in the property files correctly. Next, I removed the property file from the applib directory and put it in the [ORACLE_HOME]/j2ee/home/shared-lib directory. I restarted the server and tried again. This time, the property file was not found.
This made me wonder about the differences between the two. The applib directory is used by all applications. Libraries and other files that are put in this directory are loaded before libraries and files in the WEB-INF/lib directory of your ear file. In the Oracle® Containers for J2EE Developer’s Guide 10g Release 2 (10.1.3) , shared libraries are explained in great detail. Basically you use these if you have an application that needs to use a different library than the standard library that is packaged with OC4J. An example can be the XML Parser you want to use, or a different version of the Oracle JDBC driver. Another reason to use shared libraries is to share proprietary classes across specific applications, rather than across all applications. To accomplish this, you obviously need to configure your application to work with the shared libraries. The developers guide describes the steps to do this. So if I really wanted to try if the shared-lib folder works for the property file, I would have to configure the shared libraries and my application. I decided not to bother...I am not sure what happens if the application is clustered, but since this was not a requirement when I got the question, the applib directory looks like the simplest solutions that could work in this particular case.

Filed under: Java, Oracle
2 Comments