Does anyone from JBoss actually read these forums?
I will go and examine our code and find out if & where the finder is being called again within the transaction that is persisting to the database.
I've reviewed our code and the problem is occuring because we are defining the properties of an Entity as a one-to-many relationship between the Entity CMP bean and EntityProperty CMP beans:
<relationships > <ejb-relation > <ejb-relation-name>Order-OrderProperty</ejb-relation-name> <ejb-relationship-role > <ejb-relationship-role-name>property-associated-with-order</ejb-relationship-role-name> <multiplicity>Many</multiplicity> <cascade-delete/> <relationship-role-source > <ejb-name>OrderPropertyEntity</ejb-name> </relationship-role-source> <cmr-field > <cmr-field-name>orderEntity</cmr-field-name> </cmr-field> </ejb-relationship-role> <ejb-relationship-role > <ejb-relationship-role-name>order-has-properties</ejb-relationship-role-name> <multiplicity>One</multiplicity> <relationship-role-source > <ejb-name>OrderEntity</ejb-name> </relationship-role-source> <cmr-field > <cmr-field-name>orderProperties</cmr-field-name> <cmr-field-type>java.util.Set</cmr-field-type> </cmr-field> </ejb-relationship-role> </ejb-relation> </relationships>
Within our transaction we hold the reference to the OrderEntity bean, but not the OrderPropertyEntity beans, and it seems as if the latter are being flushed when the option-D refresh thread is triggered. That leaves the OrderEntity bean with references to empty OrderPropertyEntity beans.
(The JBoss documentation says that option D does not satisfy the EJB spec - is this why?)
Any ideas as to how we can work around this?
Actually I managed to reproduce the problem even after removing the relationship (i.e. only setting fields that were not part of the relationship), so this is not the reason at all. Please ignore my last post.
I've have managed to write a generic test case that can be used to prove that a CMP entity's attributes are rendered empty by the Commit Option D refresh thread even if you do not call the a find() method a second time.
Using a simple servlet (for want of a better way to talk to the EJBs) I first connected my servlet directly to a CMP entity bean. The entity bean transaction demarcation was set to RequiresNew.
In-between setting the attributes of the entity I suspended the current thread. This allowed the thread that controls the Commit Option D that controls the cache to perform a flush(). I then tested the values of the attributes that I had just set... and they were fine. Not a problem.
Next I introduced a session bean to act as a processor/proxy for the entity bean. The transaction demarcations were set to Required for the Entity bean, and RequiresNew for the session bean. The processor had a createEntity() method that would create a new entity instance and then start setting the values of the new entity's attributes. After setting a couple of attributes I again suspended the current thread to allow the flushing of the cache to take place. When I inspected the values of the attributes I had just set, they were empty!
The session bean had not performed anymore lookups or called anymore finder methods, and yet the entity it was working with had been completely reset.
This doesn't appear to be a particularly robust feature of JBoss, but it may be that I am choosing the wrong settings somewhere and would appreciate a little investigation into this matter.
I have an EAR file available that can be deployed to show this bug in action, but who do I submit it to?
Does anyone at JBoss want to comment on this bug?
I can supply a test case that replicates it.