> -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED] On Behalf Of Doug Bateman > Sent: Monday, February 16, 2004 9:37 PM > To: [EMAIL PROTECTED] > Subject: Re: Re-entrant EntityBeans > > > On Thu, 5 Feb 2004 11:31:06 +0530, Alok_Band > <[EMAIL PROTECTED]> wrote: > > > >What are anomalies of Re-entrant EntityBeans? > > Excellent question. > > According to the EJB Specification (EJB 2.0 Spec, Section > 10.5.11, Page 189), the real danger appears when there is a > chance that 2 seperate threads, each part of the SAME > transaction, attempted to use the same entity at the same > time, which could lead to nasty race conditions. The EJB > container may not be able to distinguish between this > scenerio and a reentrant scenerio. The operative piece here > is that for this scenerio to occur, the two threads must > share a transaction context (otherwise the container could > detect the condition and prevent it). > > This brings up 2 even more interesting questions: > > + When is it possible for 2 seperate threads to share a single > + transaction > context? Couldn't this cause all sorts of other problems > inside the container as well?
It could happen with a UserTransaction. The problems you're quickly noting. Also, sharing a transactional context could be part of enroling in an XA transaction; this depends on container/server implementation. > > + Is there ever a viable design scenerio where reentrant > Entities would > + be > desirable? In other words, is there a valid design scenerio > where you ever want Entity A to call Entity B which might > then call back to Entity A (the definition of a reentrant call)? > > The only possible scenerio I can think of would be if you're > recursively visiting a graph of related entities in an > attempt to build a tree of related value-objects (ie > Order-LineItems-Products). However, this short of > "loop-back" scenerio is exactly why I'd avoid recursively > building my value-object relationships in the entities... > prefering to instead do this from a session bean. Can anyone > think of a real-life scenerio where using reentrant entity > beans would actually be the best design? Doing this kind of thing in either the Entity Bean or the Session Bean won't impact reentrancy. Esp. if the relationship is done in a tree like fashion. Usually the penalty for reentrant Entity Beans is stiff only if some of the entity beans are accessed using Remote Interfaces. The best design will be structured in a very maintainable fashion. That usually means that Session beans will handle use-cases that span multiple non-dependant solution domain entities (I would define Order-LineItem-Products as dependant). Finally, remember that the reentrancy condition implies that you call the same *instance* twice in a call stack. App servers (the one's I know) handle this by adding the EBs Handle into the transactional context, and thus making sure the same instance (with uncommitted modifications) of the EB is called within a transaction activity when the same PK is referred. HTH, JP =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
