Thread pools with Java’s ExecutorService

Some days ago I had to do a migration of legacy data to a new system. The task was mainly about copying stuff from the old system to the new system. This was done via a REST interface of the new service. So the task was completely IO bound and most of the time the migration script was waiting for a response of a REST call. A perfect situation to do some threading!

The idea was to start a new thread for every data record to migrate. So while the first record was already waiting for the REST response, the second record would be build together and sent to the REST service and so on. This would hopefully speed up the process a lot.

However, since I got about ~5000 records, I didn’t want to spawn a new thread for each of those. 5000 threads (at the same time) would be hard – for my own system as well as for the REST service. So I decided to use Java’s ExecutorService to spawn a fixed number of threads at any time:

In the example above I do the following:

  1. I make an ExecutorService instance with a fixed size of 10 threads. So at any time, a maximum of 10 threads will run!
  2. I execute 100 threads. However, if 10 threads are already running, the ExecutorService will wait until one of those has finished, before starting the next one.
  3. I call shutdown() and awaitTermination(...) on the ExecutorService which will make it impossible to run new threads (except the 100 threads submitted before) and block until all 100 threads have finished.

This pattern makes it possible to submit a large number of threads for execution, but only run a fixed number of threads in a pool.

Best regards,

Anti Patterns

A couple of days ago I have been to a tech talk from eBay in Berlin. The talk was hold by a developer of the eBay Kleinanzeigen team (a subsection of eBay in Germany) who talked about development patterns his team learned during the years. He mentioned behavioral patterns, design patterns and coding pattern his colleagues and he discovered as good practices for their projects. Since nearly everything could be seen as a pattern, the talk was a mix of learned lessons and actual advises on how to structure code. Cool! It is always good to talk and hear about coding experiences and it also reminded me at something which is often more important than patterns: anti patterns!

2015-01-22 19.27.11

The idea of anti patterns always comes to my mind when I’m reading some old code. And it comes more often if the code is super sophisticated and fancy. The more people try to engineer their code, the more they build things which looks like some complicated pattern but are actually anti patterns.

You like some examples? Here’s a very trivial anti pattern, not a big thing. It’s just a bad habit. It looks like that:

Anything wrong here? No, just a factory. Anything useless? Yes, a little bit. It’s very likely to see a class with only static methods (like a factory) to have a private constructor. Why? Because the developer thought it’s evil to instantiate it and he must prevent it for the safety of everybody in the room! So he creates something which look like a singleton (but isn’t). He does this in every suitable class, because it’s his patterns. But it is actually nothing. What would happen if you instantiate such an object? Nothing. And if you call static methods on that object? Nothing, too. It doesn’t look good, but it would work and your IDE would warn you. So what problem does it solve? There’s none. It just looks like some useful pattern, but actually does nothing but clutter your code. An anti pattern.

There are more of those small bad habits (like using final everywhere) but also bigger ones (like an interface for everything). I’m going to think about this a little more and come up with another example!

Best regards,

Making a Spring bean session scoped

Spring can not only inject beans (components, services, entities, however you want to call them), it can also inject them according to a certain scope. This is great if you have state-full objects which belongs (for example) to a dedicated user and not to the whole application. To do that, Spring introduced the @Scope annotation.

The usage of @Scope is straight forward: just annotate your bean with it and specify the scope to use:

The value of @Scope can be one of singleton (one single instance for the whole app), prototype (a new instance for every injection), request (an instance per web request) or session (an instance per web session). See here.

The last two scopes (request and session) are only available in Spring web applications where the current session is exposed. To do so, you need to add a listener to the web.xml which makes the context available:

If you got both, your annotated bean and the listener in your web.xml, you will typically have another problem: how to use a session scoped bean in a normal (not session scoped) service?

To solve this problem, Spring provides a proxy mechanism. This means Spring can wire a proxy with the same interface as your actual bean instead of the bean itself. The proxy will not be session scoped (it will be a singleton), but it will fetch the according session scoped bean for each request. This means you can wire your session scoped bean in a not session scoped service and the proxy will do the rest behind the scenes.

To use such a proxy, you can just add it to the @Scope annotation like that:

If you do so, you will discover the next problem soon: what about your integration tests you made which probably will fail now as they got no session? The easiest fix for this, is to add the following bean configuration, which adds a session context for each thread (see the post of Tarun Sapra for the original description):

Best regards,