Bugs item #575815, was opened at 2002-07-01 03:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=575815&group_id=22866
Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: Accepted Priority: 5 Submitted By: Stephen Coy (scoy) Assigned to: Dain Sundstrom (dsundstrom) Summary: CMR and commit option A Initial Comment: I think that Dain's fix to properly report java.lang.IllegalStateException when accessing CMR collections outside of their original transaction is broken when "Commit Option A" is in effect. I have a "User" entity bean that has a many-to-many relationship with a "Role" entity bean. The "User" bean has a method which iterates over the roles looking for a particular attribute (which we should probably re-implement as an "ejbSelect" method). When the bean is configured with "Commit Option A", the first access of this method works fine, subsequent accesses throw a java.lang.IllegalStateException containing the text "A CMR collection may only be used within the transction in which it was created". Reverting the configuration to the default "Commit Option B" works OK. The code was built from "Branch_3_0" as of about four hours ago, although the problem manifested itself toward the end of last week. I'm using the current Apple 1.3.1 JVM for what it's worth. ---------------------------------------------------------------------- Comment By: Erden (erden) Date: 2002-07-16 14:15 Message: Logged In: YES user_id=578891 I don't think the change solved the problem. I have downloaded/build jboss Branch_3_0 as of yesterday (16/07/2002 - with the proposed change). It still doesn't work. With commit B it works fine. When you switch to commit A. It works fine first time, then every time it throws a exception RuntimeException: java.lang.NullPointerException at org.jboss.ejb.plugins.cmp.jdbc.bridge.RelationSet.getIdList (RelationSet.java:57) at org.jboss.ejb.plugins.cmp.jdbc.bridge.RelationSet.iterator (RelationSet.java:260)... Erden ---------------------------------------------------------------------- Comment By: Michael Newcomb (mnewcomb) Date: 2002-07-01 17:06 Message: Logged In: YES user_id=382427 I have a fix, but not sure if it is completely what we want to do. The fix would be inside JDBCCMRFieldBridge, when the transaction completes, instead of nulling out the set which held the related keys, I went ahead and reset the CMR field's persistence context. That insures that the CMR field is invalid at the end of every transaction and on subsequent transactions if forced to reload... Michael ---------------------------------------------------------------------- Comment By: Michael Newcomb (mnewcomb) Date: 2002-07-01 15:22 Message: Logged In: YES user_id=382427 >From my initial analysis, it looks like when the transaction completes, it nulls out the id set handle but fails to invalidate the field state. Invalidation only occurs when when resetPersistenceContext is called and that isn't called with commit option A (except for the first time, right?). When this happens, the RelationSet is still valid, but there is no backing id list and so RelationSet.getIdList pukes... In the process of trying to verify this theory. Michael ---------------------------------------------------------------------- Comment By: Stephen Coy (scoy) Date: 2002-07-01 15:05 Message: Logged In: YES user_id=463096 I tried this with no trx specs at all and also with the caller setup with RequiresNew and Mandotory on the collection getter. Made no difference. Note that it works perfectly when using Commit Option B. ---------------------------------------------------------------------- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-07-01 14:51 Message: Logged In: YES user_id=251431 Are you trying to access a CMR collection from another transaction or without a transaction? If you are, you should be getting this exception. ---------------------------------------------------------------------- Comment By: Michael Newcomb (mnewcomb) Date: 2002-07-01 13:31 Message: Logged In: YES user_id=382427 This is occurring on HEAD as well. I have not tested the multiple invocation scenario, but this exception is thrown even when I redeploy my application with commit option A on. I have to restart JBoss to clear the exception. I will be running some more tests to see if I can more thoroughly define the problem I'm seeing. Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=575815&group_id=22866 ------------------------------------------------------- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
