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
