Bill, Yes, it would only happen for re-entrant beans. I did not see through the whole source codes. But if any Exception happened during the invoke(), wouldn't there a memory leak in that HashMap?(Of course, this argument applys to the old "finally block" implementation, too) If there is no memory leak issue, I think register() before invoke() is ok because the old implementation would always register it in "finally block". Henri -----Original Message----- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 04, 2002 7:26 AM To: Henri Chen; [EMAIL PROTECTED] Subject: RE: Bug in EntitySynchronizationInterceptor.java? Henri, Good catch. I finally actually read your bug report :) BTW, this would only happen if your entity bean is re-entrant, right? The fix for this I believe is in EntitySynchronizationInterceptor. I think it is ok to register() before invoke() since register() will always happen anyways. Anybody see anything wrong about that? Henri, when I commit to 2.4.5 (Branch_2_4) and 3.0, do you have a test for this? Thanks, Bill > -----Original Message----- > From: Henri Chen [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 02, 2002 11:30 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: FW:Bug in EntitySynchronizationInterceptor.java? > > > I found I post my former mail to > [EMAIL PROTECTED] and that is not > correct. So I forward the mail to the correct list again. Sorry > for the inconvenience. > ------------------------------ > Dear Bill, > > The transaction did propagate correctly and without problem > because it is not a different transaction issue. > > The question is that the new activated instance (when calling > m1()) is not put into the HashMap IMMEDIATELY. It does it in the > "finally block" and that is after the invoke chain. So if the > implementation of m1() calling m2() thru the entitie's component > interface (i.e. calling thru container), the m2() would go thru > the EntityMultiInstanceInterceptor again. The interceptor would > try to looks that HashMap for the instance. Oops! It would still > activate a new instance of the same PK because the instance > activated during calling in m1() is not put into the HashMap YET > (because the invoke chain is not completed yet.) > > This is what I think it might be a bug. > > Henri > > P.S. It did cause trouble in my code. I saw two instances were > consecutiously activated and I read the source code of jboss > release 2.4.4. > > -----Original Message----- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 22, 2002 10:10 PM > To: Henri Chen; [EMAIL PROTECTED] > Subject: RE: Bug in EntitySynchronizationInterceptor.java? > > > I don't think so....Let me go through your comments again just to > make sure. > > I keep a transaction->entity map. Before an instance is created anew, the > EntityMultiInstanceInterceptor looks in a HashMap to see if the > instance has > already been created for this transaction. The transaction should be > propagated when you call _ctx.getEJBOejct()->stubx1->m2(). > Unless there is > some bug someplace and the transaction is not getting propagated. Are you > seeing bad behaviour? Or is this just your observation just > looking at the > code? > > Bill > > > -----Original Message----- > > From: Henri Chen [mailto:[EMAIL PROTECTED]] > > Sent: Friday, March 22, 2002 1:33 AM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: Bug in EntitySynchronizationInterceptor.java? > > > > > > Dear Bill, > > > > It might be too late to associate the entity bean with the > > transaction until after the invoke chain. > > > > The following is a senario that might cause trouble: > > > > * An entity bean XBean with component interface method m1() and m2(). > > * Some session bean Y calls XHome.findByPrimaryKey() to get the > > component interface stub x1. > > * Y calls x1.m1(), the EntityMutltiInstanceInterceptor > > automatically activate and load an instance of the XBean. > > * The implementation of method m1() in XBean use > > _ctx.getEJBObject() to get the stub x1, and calling m2() thru the > > container again. > > * The EntityMutltiInstanceInterceptor, AGAIN, automatically > > activate and load ANOTHER NEW INSTANCE of x1; and then invoke > > m2() on this new instance and return. > > * The EntitySynchronizationInterceptor associate 2nd instance > > into txEntityMap. > > * The m1() on the first instance return. > > * The EntitySynchronizationInterceptor associate 1st instance > > into txEntityMap WITH the same primary key and transaction.(So > > basically, the 2nd instance is overwritten and gone) > > > > The result is that two methods m1() and m2 are called on two > > DIFFERENT instances. Therefore, the state of the bean would be > > unpredictable because all that have done inside m2() is lost. > > > > Am I right? > > > > Henri Chen > > > > PS. This is based on the jboss 2.4.4 source code, and use commit > > Option >B.%,ׯzZ)홨x%In,uޖfz{elqzm?X( ~zwXb?,ׯzZ)
