I totally agree. That is why is think ejbCreate and ejbPostCreate should be separate invocations. Basically, ejbPostCreate would act just a standard method invocation that is automatically called after create.
-dain > -----Original Message----- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 18, 2001 11:38 AM > To: Dain Sundstrom; 'Peter Levart'; Andreas Schaefer; JBoss-Dev > Subject: RE: [JBoss-dev] [ jboss-Bugs-472072 ] INSERTING AN ALREADY > EXISTING BEAN, ID = > > > Guys, We need to make sure that whether or not a cache is > used is hidden > within EntityInstanceInterceptor. This is the only thing I > care about here. > Also, you need to make sure that the EntityMultiInstance > interceptors still > work too if you're going to change these types of > interceptors. I can't > help out with this until after Christmas. But would be > willing to do the > work. > > Bill > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Dain > > Sundstrom > > Sent: Tuesday, December 18, 2001 11:58 AM > > To: 'Peter Levart'; Andreas Schaefer; JBoss-Dev > > Subject: RE: [JBoss-dev] [ jboss-Bugs-472072 ] INSERTING AN ALREADY > > EXISTING BEAN, ID = > > > > > > > On Tuesday 18 December 2001 11:17, [EMAIL PROTECTED] wrote: > > > > > > > > � � public void ejbPostCreate ( > > > > � � � � � � String cid, > > > > � � � � � � String id, > > > > � � � � � � String street, > > > > � � � � � � String city, > > > > � � � � � � String zip, > > > > � � � � � � String state) > > > > � � � � throws CreateException { > > > > � � � � //Log.trace("AddressBean.ejbPostCreate..."); > > > > � � � � postCreate(cid); > > > > � � } > > > > > > > > � � private void postCreate (String cid) { > > > > � � � � //Log.trace("AddressBean.postCreate..."); > > > > � � � � try { > > > > � � � � � � Context ic = new InitialContext(); > > > > � � � � � � LocalCustomerHome home = (LocalCustomerHome) > > > > � � � � � � � � ic.lookup("java:comp/env/ejb/CustomerRef"); > > > > � � � � � � LocalCustomer customer = > > > > home.findByPrimaryKey(cid); > > > > � � � � � � > > > > customer.addAddress((LocalAddress)context.getEJBLocalObject()); > > > > � � � � } catch (Exception ex) { > > > > � � � � � � context.setRollbackOnly(); > > > > � � � � � � ex.printStackTrace(); > > > > � � � � } > > > > � � } > > > > > > > > > > > > ... the Customer <-> Address is a 1-n relation. If instead > > > > of customer.addAddress(address) the case is rewriten as > > > > address.setCustomer(customer) then this exception is not > > > > thrown... > > > > > > Ok, the above line should be writen: > this.setCustomer(customer), not > > > address.setCustomer(customer) (no new invocation)... > > > > > > If I remember correctly the problem lies in the fact that while > > > ejbPostCreate() method is executing, the > > > EntityEnterpriseContext of the bean > > > is not yet put into the cache, since this is done in > > > EntityInstanceInterceptor after the return from the > > > getNext().invokeHome(mi). > > > > I looked this up. The problem is that the createHome > invocation calls > > createEntity on PersistenceManager which handles both ejbCreate and > > ejbPostCreate. > > > > > If ejbPostCreate() calls other beans through their local > (or remote?) > > > interfaces that in turn invoke our bean (is adding a local > > > interface to the > > > CMR field considered an invocation on the bean being added? > > > Some kind of > > > special invocations are needed to update both sides of > relationship I > > > suppose), a second EntityEnterpriseContext is created and > > > inserted into the > > > cache and this clashes with inserting the first > > > EntityEnterpriseContext later > > > in the EntityInstanceInterceptor.invokeHome(). > > > > Yep, you got it. > > > > > So how is this actualy possible if the first bean is > > > non-reentrant? So adding > > > a local interface to a CMR field is not considered to be an > > > invocation on the > > > bean being added, or is not checked for re-entrancy > > > constraints at least. > > > > Adding or being added to a CMR collection is not considered an > > entrant call. > > > > > The correct way would be for EntityEnterpriseContext to be > > > put into the cache > > > between the calls to ejbCreate() and ejbPostCreate() methods, > > > but this could > > > not be done in EntityInstanceInterceptor then. > > > > I disagree. I think the way to fix this is to break the createHome > > invocation into to invocations. One to handle the ejbCreate stage > > and one to > > handle the ejbPostCreate stage. I think this would be much > easier to > > understand as this the way most calls work. Who ever fixes this > > could also > > add support for EJB 2.0 createFactoryStyle methods (create > > methods now must > > only start with create). > > > > > So here's another crazy idea... > > > > > > What about some kind of generic callback Interface that could be > > > registered in an ordered List within the MethodInvocation as > > > it is passed > > > down the invocation chain of interceptors. This way an > > > interceptor could > > > register itself (or it's inner class implementing callback > > > interface). The > > > callbacks would then be invoked in the LIFO order of > > > registration to simulate > > > the order of normal invocation returning but this would be > > > done between > > > ejbXXXX and ejbPostXXXX calls where such twins exist > (currently only > > > ejbCreate/ejbPostCreate, but you never know what SUN will add > > > in EJB 2.1 and > > > 3.0)... > > > > > > This is not elegant, I know. > > > > > > Peter > > > > I think breaking this into two distinct calls will be much easier to > > understand. > > > > -dain > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
