I have several comments to make. First Session EJBs are usually used to implement the 'Facade Pattern'. This is definitely A Good Idea. Plain old java objects will not have access to the declarative transactions of the EJB container, therefore even if you used POJOs to facade your calls to the Entities, each and every call to each individual entity method is a separate transaction.
Eg user fills in 'new user' form. You put this data into a UserLogin data transfer object (a POJO that represents the user's data) and then pass the DTO to the Facade POJO. Then it sets the new data into the User Entity EJB. EACH AND EVERY call to the Entity methods like entity.setName(name), entity.setPassword(password) is a new and different transaction. So if all succeeds but the password, then of course only that method fails and is rolled back and what you have is a user object that is ok except for the password, which is blank or left as is. You COULD wrap all this in a programmatic transaction (write your own transaction boundaries) but this is not recommended. And you never get rid of the other main issue, which is multiple calls to the EJB container, which menas mutiple serialisations and marshalling/unmarshalling of the data -- that is inefficient and will cause performance problems. If you use a Session EJB, stateful or stateless, the whole kit and caboodle is one single, atomic, transaction. If any method of the Entity fails, the whole lot is rolled back -- including the create(). Also, the transaction requirements, and the transaction isolation are purely a factor of administration and can be changed without touching any java code, it's in the EJB deployment descriptor. Additional benefit -- only one remote call to the EJB container is ever made, which is efficient. It is my opinion that non-use of the Facade Pattern is the number one cause of performance problems in EJB systems. End-user systems (ie. servlets, JSPs, end user code) should never talk to Entity EJBs directly. ALWAYS use DTO Pattern and Session EJB Facade Pattern. Then your systems are also isolated from changes in the data model of the Entities -- their API is purely the DTOs and the Session Facades. > myself included, b/c you want to > control transaction(s), etc.. yourself in some sort of framework > encapsulating the interactions > instead of in the EJBs themselves. I don't understand this bit. Is it advocating programmatic control of transaction boundaries instead of declarative control using the deployment descriptor? If so I would have to disagree, programmatic transactions in a J2EE environment at least are usually a Bad Thing. The session EJB, whether stateful or stateless, gives you that declarative transaction ease of use. regs scot. --- You are currently subscribed to jdjlist as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
