We found the solution for our project. Because of the (old) architecture of our project, we are forced to use a non-standard configuration. That is, we use Standard CMP 2.x EntityBean with cache invalidation for our Entity Beans, with commit option A _and_ Optimistic Locking.
The Wiki article http://wiki.jboss.org/wiki/Wiki.jsp?page=CMPCaching clearly states that when we want global caching we must use Pessimistic Locking (which is default btw.) The problem we had with Pessimistic Locking is that it produced a lot of "Application deadlock" errors so instead we opted for Optimistic Locking which gave us "CMR field value is already loaded". Our Session Beans use "Supports" by default for transaction type and "Required" only for methods which need to write to the database. Our Entity Beans were completely "Required". Since there was no need for the getter methods to be "Required", we made them read-only and "Supports" to make sure they don't start a new tx. We use Xdoclet: | * @ejb.transaction | * type="Supports" | * @jboss.method-attributes | * read-only="true" Read more about read-only here http://www.onjava.com/pub/a/onjava/2003/05/28/jboss_optimization.html This configuration worked for us. We think that due to our erroneous configuration, the CMP container tried to load data multiple times into the cache, which JBoss didn't allow. The new configuration doesn't start any tx for reading access (we traced it and know that). It also seems to behave correctly by loading instances only once into the cache and then reading from it too. Another solution is to use Instance Per Transaction CMP 2.x EntityBean but that is not acceptable because it's too slow. Hope that helped. -- Alex View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975441#3975441 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975441 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
