9 Replies Latest reply on Apr 25, 2005 11:09 AM by starksm64

    Unable to passivate due to ctx lock

    cbradbury

      Hi,

      We are having a problem using commit option D in that the thread that periodically flushes the cache seems to be leaving us with unpopulated entities if an entity is being updated at the time of the flush.

      Unfortunately I posted on the wrong topic, but the link to all the info I posted so far is here:

      http://www.jboss.org/index.html?module=bb&op=viewtopic&t=59610

      Thought it best to move it over to this topic as it is more appropriate.[/url]

        • 1. Re: Unable to passivate due to ctx lock
          cbradbury

          Does anyone from JBoss actually read these forums?

          • 2. Re: Unable to passivate due to ctx lock
            starksm64

            Yes.

            • 3. Re: Unable to passivate due to ctx lock
              aloubyansky

              I guess, your problem is this
              http://jira.jboss.com/jira/browse/JBAS-979

              • 4. Re: Unable to passivate due to ctx lock
                cbradbury

                Brilliant, thankyou!

                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.

                • 5. Re: Unable to passivate due to ctx lock
                  cbradbury

                  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?


                  • 6. Re: Unable to passivate due to ctx lock
                    cbradbury

                    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.

                    • 7. Re: Unable to passivate due to ctx lock
                      cbradbury

                      OK,
                      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?

                      Cheers,
                      Carl.

                      • 8. Re: Unable to passivate due to ctx lock
                        cbradbury

                        Does anyone at JBoss want to comment on this bug?
                        I can supply a test case that replicates it.

                        • 9. Re: Unable to passivate due to ctx lock
                          starksm64