Deadlock: caused by cached entity beans?

[michel1]

Hi,

in the application I'm working on, we require the use of many entity bean instances every second. Unfortunately, scaling hardware is not an option. For sake of clear code, we would prefer to use Entity Beans with CMT and CMP.

This leaves us with better performing algorithms. One way that we figured out to improve performance is to keep a cache (in a Map) of all recently loaded entity beans. Clients are not using the home interface to get entity instances, but this cache. This results in a 10-fold speed-up.

But, our application is deadlocking now. Can it be that this cache is confusing transactions?

[davidjencks]

I think it is highly unlikely your cache could be causing deadlocks. What are the symptoms? eb or jboss deadlock? Are many threads using the same cached remote interface proxy instance simultaneously?

What do you mean by "client"? Is it in jboss vm (maybe a session bean) or another vm?

If the client is in another vm, why is it accessing entity beans directly anyway? This is apt to cause too many remote calls and too many transactions. Even just wrapping your entity bean calls into a stateless session bean will have the same effect as your client side cache, using the internal jboss entity cache (I think).

[michel1]

We run all code in the same VM (at the moment, though this can change in the nearby future).

At the moment, we kicked out most of the caches and replaced them by
1) isModified() on all Entity EJB implementations
2) <tuned-updates>true<../> for all Entity Beans
3) Transactions starting in the client application (usually a SessionBean or Tomcat). To make transactions work more easy in Tomcat, we build a transaction aware request interceptor for Tomcat (which we are willing to release to the JBoss project).

This solves the deadlock problems and results in a reasonable speed.