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? + 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? Doug =========================================================================== 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".
