Bugs item #789653, was opened at 2003-08-16 00:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=789653&group_id=22866
Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Brian Stansberry (bstansberry) Assigned to: Nobody/Anonymous (nobody) Summary: Transaction issues w/ CMR entity on readonly calls Initial Comment: There seems to be a problem in 3.2.2RC2 in that CMT transactions are not always propagated to the related entity when it is accessed via CMR. The problem seems to occur when the CMR accessor method being invoked is read-only. The transaction interceptor in the related entity reports that the transaction associated with the method invocation is null. In what may be a separate bug, if the related entity has previously been bound to the (now missing) transaction, the BeanLock reports transaction contention on the bean, and the CMR access does not complete. This seems like correct behavior from the viewpoint of the related bean. But, I noticed the QueuedPessimisticEJBLock schedule() method will basically loop forever trying to schedule the CMR call, continuing to try and fail long after the original transaction times out. I forgot and left a test server running and find it still trying 48 hours later. The attached test case demonstrates both these issues. Sorry if it does more than it needs to to demonstrate the issue; its basically a stripped down version of a section of a very complicated app; I wrote the test to see if the problem was in the app or JBoss. The test case consists of entity CMRTree that functions as a sort of tree. Entity instances participate with other instances of the same bean in one-to-many parent-child relationships. The test class accesses the entities via a SLSB whose purpose is basically to wrap calls to the entities in a transaction. The setup of the test creates 3 instances of CMRTree "Parent", "Child1" and "Child2". Parent has no parent and is the parent of Child1. During the setup phase, Child2 has no parent. The real test is a call to the SLSB's rearrangeNodes method. The SLSB finds Child1 and 2. It accesses Parent via a CMR call from Child1. It uses the reference to Parent to set Parent as Child2's parent. Parent is now bound to the transaction due to a change in its child relation. The SLSB then attempts to put Child1 and Child2 in proper order by passing Child1 as an arg to Child2.setPrecededBy(). Child2.setPrecededBy does a validation to make sure its parent is the same as the parent of the node that has been passed. The failure occurs when Child2 attempts to access Parent via a call to Child1.getMenuParent(). It succeeds in accessing parent via a call to its own getMenuParent() method; the failure comes on the call via Child1. If CMRTree's get* methods aren't marked readonly, the failure doesn't occur. I haven't tried this test in 3.2.1, but the real app it's derived from works in 3.2.1. The attached zip can be extracted into a checkout of jboss-3.2; it's structured to drop into the JBoss testsuite. The only exception is file jboss- 3.2/testsuite/build.xml.diff, which, well you can probably guess what it is ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=789653&group_id=22866 ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
