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;
