Transient Entity

Transient Entity

Posted By: Toby Hede on August 16, 2001

Anecdotal evidence suggests that many developers remain skeptical about the value of Entity Beans, especially prior to the EJB 2.0 specification. Many system designers and developers choose not to invest precious resources in a technology that remains unproven in large scale deployments. Transient Entities are session beans that handle interaction with a datastore, generally a relational database. As Transients are only instantiated as needed and exist only for the life of the Session Bean, significant load reductions can be seen. Transient Entities are essentially the architecture enforced when using Microsoft's COM+ model (As COM+ has no Entity BEan equivalent). Two types of transient entity are available for use: Conversational and Non-Conversational. Conversational Transients are modelled on Stateful Session Beans and exist for the lifetime of the client session. Data can therefore be cached in the Transient Entity, reducing the load on the underlying datastore. Conversely, Non-Conversational Transients exist for the lifetime of the method call and therefore no data can be cached in the Entity itself. Non-Conversational Transients are the most efficient and scalable way of handling perisistence in the application server (See Notes). Transient entities typically wrap both business logic and data, in a traditional OO model. However, Transients can be modelled on Entity Beans and be used as 'simple' data entity objects with no included business logic. A typical Transient architecture has the following form :   Client -> TransientEntity -> Datastore or this alternative ('pure data' Transient):   Client -> BusinessObject -> TransientEntity -> Datastore Sample Code: In this example our Account object is a Non-Conversational Transient Entity. We create an 'AccountModel' for our data (this is essentially the ValueObject pattern for data transfer). This is an immutable object and data is set on creation. public class AccountModel implements Serializable {    private String accountID = null    private String name = null;    private String email = null;        public AccountModel(String accountID, String name, String email)    {     this.accountID= accountID;     this.name = name;     this.email = email;    }    ...    // create getters for each value    ... } We create a remote interface for our EJB. In this case we are using AccountModel to encapsulate data for create and update, but we could explicitly pass the necessary parameters ( or even use either strategy as neeed dictates). public interface IAccount {   // standard Transient create-read-update-delete methods      public AccountModel create(AccountModel model) throws EJBException;   public void delete(String id) throws EJBException;   public AccountModel read(String id) throws EJBException;   public void update(AccountModel model) throws EJBException; } The exceptions returned should probably be extended to include more applicable and descriptive errors. Now we implement the Session Bean itself. In this model we pass the AccountModel to a factory-based Data Access Object that handles the underlying JDBC implementation. This is similar to the system used by the latest version of Sun's Petstore blueprint application. public class AccountEJB implements SessionBean {    public AccountModel create(AccountModel model) throws EJBException    {     try {     IAccountDAO dao = AccountDAOFactory.getDAO();     dao.create(model);     }     catch(Exception e) {     // handle error     }    }    public void delete(String id) throws EJBException {}    public AccountModel read(String id) throws EJBException {}    public void update(AccountModel model) throws EJBException {}           ...        // remember to implement SessionBean inherited methods        ... } The implementation of the IAccountDAO interface is a Data Access object that handles the database interaction. In this implementation, we are actually using a Stored Procedure with the database to handle the query itself. This keeps messy SQL out of our Java code. public void create(AccountModel model) {    CallableStatement stmt = null;        ...   getDBConnection(); String qry = "Account_Create (?, ?, ?)"; stmt = con.prepareCall("{call " + qry + "}"); stmt.setString(1, model.getID()); stmt.setString(2, model.getName()); stmt.setString(4, model.getEmail()); stmt.executeUpdate();     ... } The use of stored procedures is on of the major benefits of handling peristence manually. Significant performance benefit can be seen from utilising stored procedures effectively, as the database can optimise and cache the execution plan for the SQL statement. The client can then access the AccountEJB, calling the relevant methods as necessary. Conversational Transients: In a Conversational Transient, the AccountEJB would be a Stateful session been and would hold a local instance of the AccountModel. This model then gets reassigned as methods are called. AccountModel model = null;    public AccountModel create(AccountModel model) throws EJBException    {     try {     IAccountDAO dao = AccountDAOFactory.getDAO();     dao.create(model);     this.model = model;     }     catch(Exception e) {     // handle error     }    }   Care must be used in managing Conversational Transient Entities as there is real danger of corrupting data. One technique is to set flags in the database - in this technique each each data row flag that marks locking and all queries return only when this flag indicates the record is not locked. Other strategies are cedertainly possible.   Consequences: Conversational Transients should only be used in cases where the existence of a client session precludes other sesions, applications or systems altering the underlying data. This generally means that when a Conversational Transient is used, some sort of locking mechanism should be in place for the underlying data. Failure to do so will result in possible data corruption as cached data becomes stale and is no longer an accurate reflection of the current state of the underlying database. Transient Entities are not as simple as CMP entity Bean solutions, because all database interaction code must be produced manually. Although this can be reduced to some extent by developing an appropriate reusuable code, in some sitautions CMP Entity Beans are definitely of great benefit and should not be discounted out of hand. In using a Transient architecture, the load on the database can be increased significantly, especially in cases where the majority of data interaction is in read-only scenarios - each read invbolves another database call, where in an Entity Bean scenario, data can be effectively cached in the application server. Notes: When talking about Transients as the most efficient means of handling persistence in the ~application server~