Nope, no leak. A synchronization object is registered with the transaction. It will release the instance.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf > Of Henri Chen > Sent: Wednesday, April 03, 2002 8:34 PM > To: Bill Burke; [EMAIL PROTECTED] > Subject: [JBoss-dev] RE: Bug in EntitySynchronizationInterceptor.java? > > > 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.n ?ׯzZ)?x%In?ׯz > Z)Xy?zm?b?q??-bا~n?ׯzZ) _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
