Middleware Technologies [MCA II Yr, Anna University] by Roy Antony Arnold

Deployment

1. Must include the names of the home interface, remote interface, and implementation class.
2. Set the isolation level and transaction attribute for the bean.
3. Deployment Descriptor must be of type javax.ejb.deloyment.EntityDescriptor
4. Include the name of the primary key class.
5. Provide the list of container-managed fields
6. Must specify whether the bean is reentrant or not.
7. Provide a description for the finder methods, so that the deployer can use the container to generate them.

• BEA Weblogic uses findByCustID(), custom finder method, as follows:
  

  “findByCustID(int cusidnum)” “(=custid $custidnum)”
  

• This method takes one integer argument called custidnum.
  
• The expression “(=custid $custidnum)” is a prefix-notation expression that indicates that the method should return all instances where the database column that maps to the field custid matches the argument of the finder method exactly.

• An entity bean can have only three states:
  • Non-existence
    
  • Pooled
    
  • Ready
    
• Non-existence
  
  • In this state, the bean doesn’t exist.
  • A bean leaves this state and enters the polled state when it is added into the pool by the container, at which point newInstance() and setEntityContext() are invoked on it.
  • It enters the state of non existence when the container removes it from the pool, at which point unsetEntityContext() and finalize() are called on it.
• Pooled state
  
  • In this state, entity beans have no identity. So all are identical.
  • When an ejbFind() method is invoked, the container uses an EJB instance from the pooled state to handle the request.
  • A bean transitions from the poled state to the ready state when one of two things happen:
    • The container selects the instance to handle an ejbCreate() request, at which point ejbCreate() and ejbPostCreate() are invoked on the object.
    • The container selects the instance to be activated, at which point ejbActivate() is invoked on the instance.
  • The ejbPostCreate() method takes the same arguments as the ejbCreate() method. It is invoked only after ejbCreate() has reached completion successfully.
  • ejbPostCreate() coded to perform any special processing needed after the beanis created, but before it becomes available to the client.
  • A bean transitions from the ready state to the pooled state when one of two things happens:
    • The container selects the instance for passivation at which point ejbPassivate() is called on the object.
    • The client invokes a remove() method on the instance, at which point the instance’s ejbRemove() method is invoked.
  • When a bean returns to pooled state, it once again loses its identity and becomes one of several available instances in the pool.
• Ready State:
  
  • In this state, beans accept invocations of its business methods. It can also process invocations of its ejbLoad() and ejbStore() methods.
  • The container keeps the state of the bean with its representation in the database.
  • ejbLoad() reads data from the database and uses it to popular instance variables, and ejbStore() writes data from the instance variables to the database.
  • When a bean is activated, the container automatically invokes its ejbLoad() method.
  • Similarly, before the bean becomes passivated, its ejbStore() method is invoked.
  • So, no logic needed in the ejbActivate() and ejbPassivate() to handle state synchronization between the objectand the database.
• Reentrant Instances
  
  • It is possible, in narrow circumstances, to make an entity EJB reentrant.
  • This situation occurs when the entity bean uses another entity bean as a client, and the remote entity bean must perform a callback parent bean.

Key points:

• All entity beans must provide a findByPrimaryKey() method in their home interface. Clients use this finder method to locate existing entity beans based on their primary key.
  
• The implementation details of the finder methods also vary depending on whether the bean has bean-managed or container-managed persistence.
  
• If the bean has bean-managed persistence the developer must implement a finder method that is declared in the home interface.
  
• If the bean has container-managed persistence, the container will provide implementations of the finder methods; developers need not to implement them.
  
• The container can easily generate an implementation of the findByPrimaryKey() method, because it know exactly what it needs to do and receives the primary key class.
  
• getEJBObject() returns a reference to the Entity bean’s EJBObject.
  
• getPrimaryKey() returns an object that contains the primary key for this Entity Object.
  
• In the client side, each method invocation must perform the following tasks
  
  • Serialize all arguments on the client side.
    
  • Transmit the arguments to the server
    
  • Deserialize the arguments on the server
    
  • Invoke the remote method
    
  • Serialize the return value on the server
    
  • Transmit the return value to the client
    
  • Deserialize the return value on the client side.
    

Primary Keys

• Each entity bean instance has an associated primary key.
• Logically, a primary key is a value or combination of values that allows you to uniquely specify a row of data.
• In EJB, the primary key is represented by a Java class that contains whatever unique data are necessary to lookup a particular entity EJBs.

  Example:
  

      pubic class CustomerPK implements java.io.Serializable
  

      {
  

          public int custid;
  

      }
  

• According to the EJB specification, a primary key class must implement the java.io.Serializable interface.
• This class simply carries the value for the primary key from the client to the server.
• The server inspects the class and uses the values it contains to perform a database lookup for the object of the requested primary key.
• If two entity beans have the same home interface and the same primary key, they are considered to be identical.

Bean Managed and Container-Managed Persistence

• There are two types of entity beans:
  • Entity beans with bean-managed persistence
  • Entity beans with container-managed persistence
• An entity bean with bean-managed persistence contains code that updates the underlying database.
• An entity bean with container-managed persistence contains no such code; instead, it relies on the container to update the database as necessary.
• This is simpler to implement but require a high degree of functionality from their container.
• Beans with bean-managed persistence are slightly more complex to implement, but do not require extra support from the container.

Transactions and EJB

• Table shows the various transaction specifiers, illustrating which transaction is in effect in various situations.
• The table includes two rows for each type of transaction support.
• The first row indicates what occurs if the client calls the bean without a transaction context; the second row indicates what happens if the client calls the bean with a transaction in effect.

• TX_NOT_SUPPORTED means that the bean should never be called within a transaction
  • If a client calls the bean without a transaction in effect, the bean method is invoked.
  • If the client calls the bean while the client has a transaction in effect, the container suspends the client’s transaction temporarily, invokes the bean method, and after the method has finished executing resumes the client’s transaction.
• TX_REQUIRED means that the bean’s methods must always be invoked within a transaction.
  • If the client does not currently have a transaction in effect, the container creates a new transaction, invokes the method within the transaction, and then terminates the transaction prior to returning to the client.
  • If the client does have a transaction in effect, it serves as the transaction context for the bean’s method invocation.
• TX_SUPPORTS means that the bean can be invoked in a client supplied transaction context.
  • If the client does not supply a transaction context, it invokes the bean’s method with no transaction context.
  • If the client supplies a transaction context, this context is used as the transaction context for the bean’s method.
• TX_REQUIRES_NEW means that the bean’s method must always be invoked in a new transaction context.
  • If the client has not supplied a transaction context, the EJB container creates a new one.
  • If the client has supplied a transaction context, the EJB container creates a new one anyway, suspending the client’s transaction context until the bean’s transaction has been completed.
• TX_MANDATORY means that the client is required to supply a transaction context
  • If the client attempts to invoke a TX_MANDATORY bean without a transaction context, the container will throw a TransactionRequiredException to the client.
  • If the client supplies a transaction context, the bean will use this context to invoke the method.

• TX_BEAN_MANAGED is a bit of a special case:

• In the first case, neither the client nor the bean has a transaction context open. The bean’s method is therefore invoked without a transaction context.
• In the second case, the client has a transaction context open, but the bean does not. The client’s transaction is suspended, and the bean is invoked with no transaction context.
• In the third case, the client has no transaction context open, but the bean does. The bean’s method is invoked in its own transaction context.
• In the fourth case, the client has a transaction context open, as does the bean. The client’s transaction is suspended, the method is invoked in the bean’s transaction context, and the client’s transaction context is resumed after the method completes.

• TX_BEAN_MANAGED transaction also differs depending on whether the session bean is either stateful or stateless:
  • A stateful bean can maintain an open transaction across method invocations. That is, it can open a transaction in one method, respond to several method invocations within that transaction, and then close the transaction in yet another method. In this situation, the container suspends the bean’s transaction context after each invoked method completes, then resumes it when the next method is invoked.
  • A stateless bean cannot maintain an open transaction across method invocations. These can potentially be invoked by many different clients during the course of their life, so it would be erroneous to attempt to maintain an open transaction context across different method invocations. If a stateless bean uses transactions, each transaction must either commit or rollback before the method returns.