Steve’s right

Libby suggested the other day we start some corporate micro-blogging.Seems Steve doesn’t want to wait: Being wrong is a positive. I’m so glad he has a clue.Among other things I see he’s bringing the positive side of flame wars to the masses. Go, go, go! I wonder where it’ll end up.

Spring+JPA == too much magic

From The Principle of Too Much Magic (written early 2003):

Many programmers have a tendency to be Too Smart. Being Smart, they introduce various kinds of Magic into their software. This will usually lead to a software design that is more generic, dynamic and flexible than is needed, has more features than is needed, and is hence much more complex than is needed.

I learned that lesson, and I learned it really, really well. It seems that a large part of the java developer community didn’t. We were greeted with this stack trace the other day:

[2008/03/21 11:54:32.710] WARN [openjpa.Runtime] 
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(
at org.apache.openjpa.kernel.AbstractBrokerFactory.loadPersistentTypes(
at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(
at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(
at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(
at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(
at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean$ManagedEntityManagerFactoryInvocationHandler.invoke(
at $Proxy11.createEntityManager(Unknown Source)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(
at org.mortbay.jetty.servlet.ServletHandler.handle(
at org.mortbay.http.HttpContext.handle(
at org.mortbay.jetty.servlet.WebApplicationContext.handle(
at org.mortbay.http.HttpContext.handle(
at org.mortbay.http.HttpServer.service(
at org.mortbay.http.HttpConnection.service(
at org.mortbay.http.HttpConnection.handleNext(
at org.mortbay.http.HttpConnection.handle(
at org.mortbay.http.SocketListener.handleConnection(
at org.mortbay.util.ThreadedServer.handle(
at org.mortbay.util.ThreadPool$
  • The servlet engine is jetty 5, the JDK is JRockit.
  • This is a spring-based web application. It uses the ContextLoaderListener to initialize spring, and an applicationContext.xml file to tell spring what beans to create.
  • Some other part of the app (not actually this servlet) uses JPA (with OpenJPA) for persistence, for which there is of course a persistence.xml.
  • Transaction management uses spring’s <tx:annotation-driven/>.

In other words, it’s pretty much how you would write a spring-and-jpa web application after reading the spring manual and the jpa manual and following their examples. Some scenario detail:

  • The stack trace happens on first servlet invocation.
  • It doesn’t always happen. It seems to happen more when the application is restarted while the cluster is under load.

The quiz question: what’s happening here?

Here’s a hint: classloaders are not normally thread-safe.

The bonus question: which one of dynamic proxies, byte code engineering, runtime aspect weaving, xml-based domain specific declarative scripting language, declarative transaction management, inversion of control, separation of concerns, reflection, classloader hacking, interceptor chaining, filter chaining, resource pooling, is not used in this scenario?

The job interview question: what would you do if you had a 9-machine cluster in production with this app on it, and then 2 of the nodes suddenly suffer from this problem on a restart?