Reentrant Entity Beans and EJB server design issues


EJB design: Reentrant Entity Beans and EJB server design issues

  1. Hi All,

        Does anyone take advantage of the ability of entity beans to be reentrant? The javasoft documentation states that this is allowed, but not recommended. They say something about a container provider possibly not being able to tell the difference between a second simultaneous client, and a valid loopback.
        I am using VisualAge and Websphere for development, and their documents also say that reentrant entity beans are supported but not recommended. They also state that a special coding style is required, but they do not elaborate on what is required. I am familiar with "normal" reentrant coding restrictions, having coded IBM 370 assembler many years back.
        I have also been looking through the Websphere Business Components architecture documents, and they make heavy use of design patterns that require loopbacks. In fact most of the classic design patterns, even something as simple and basic as the double-dispatch pattern, cannot be applied to entity beans because of this restriction.
        This restriction, IMHO, leads to many of the design issues that pop up in places like this board. The main example is the often asked question "Where do I put my business logic?". The usual simple answer is to put the business logic in the session beans, the more sophisticated answer involves a middle layer between the session beans and the entity beans. Both answers use the entity bean layer only as a dumb data model, with no useful behavior (i.e., business logic).
        Coming from a persistent Smalltalk (OO-Database) and persistent Java (Gemstone OO-Database) world into the EJB world, I am shocked at this major restriction. I can no longer distribute meaningful behavior over my persistent business entities. I can no longer take advantage of the many useful design patterns out there, and apply them to my persistent domain model. It seems like we are back in the world of data + algorithms.
        Some of the discussions try to place this in a positive light, talking about reusable data models, but I want my reusable objects (data+behavior) back!
        I have learned to accept this restriction until I looked at the Websphere Business Components Basic Components framework, and they take advantage of reentrant entity beans, and as a consequence they are free to use all of the classic patterns. Unfortunately, they do not provide source code, so I cannot see if they are using a special coding style.

       Is anyone out there using reentrant entity beans?

        Any thoughts out there about how this restriction has affected EJB application design?
  2. Coming from a persistent Smalltalk (OO-Database) and >persistent Java (Gemstone OO-Database) world into the EJB >world, I am shocked at this major restriction

    Well, have you read Dante's Inferno ("leave any hope ...")?
    What I can tell you is be prepared for more.

    As to your specific problem, there isn't any technical reason why an app server should not be able to tell a loopback from a concurent call, since they are required to propagate transaction context through every call.

    As to what regards the "session facade to entities" pattern: you're right, it should be classified as anti-pattern or at most "kind of workaround".

    My Best-Effort advice: don't use entity beans.
    Let aside the rentrancy issue, there are several other issues pending heavily on them.

    You can either use Jdbc/SQL, or use a third party persistence frameowrk with simple java objects.