Enterprise Bean (EJB) programming tutorials

Enterprise Beans Tutorial

Home| Forums | Join Google Group | Join Yahoo Group | Jobs

Earn Money
Trading Forex Online
  Paramount Airways
  Free Data Recovery
Cargo
Job Portal
  HSBC Investment
Management
Cheap Web Hosting
  Make Trip
  Cheap Air Travel
Leisure Hotel
  Free Air Travel
  Mutual Fund Informations
Cheapest Cellular Plan
Free Sexy Indians
  Call Center Software
  Hot Indian

Enterprise Beans Tutorial

9 Entity Beans An entity bean represents an entity kept in a persistent storage mechanism, usually a database. Inside the J2EE server, this application would represent the business entity objects with entity beans. Characteristics of Entity Beans Entity beans differ from session beans in several ways. Entity beans are persistent, allow shared access, and have primary keys. Persistence Because the state of an entity bean is saved in a storage mechanism, it is persistent.
Persistence means that the entity bean exists beyond the lifetime of the application or the J2EE server process. There are two types of persistence: bean-managed and container-managed. You declare the persistence type with the Application Deployment Tool, which stores the information in the entity bean's deployment
descriptor. With bean-managed persistence, the entity bean code that you write contains the calls that access the database. The ejbCreate method, for example, will issue the SQL insert statement. You are responsible
for coding the insert statement and any other necessary SQL calls. If the container manages an entity bean's persistence, it automatically generates the necessary database access calls. For example, when a client creates an entity bean, the container generates a SQL insert
statement. The code that you write for the entity bean does not include any SQL calls. The container
also synchronizes the entity bean's instance variables with the data in the underlying database. These
instance variables are often referred to as container-mananged fields. You declare the container-managed fields with the Application Deployment Tool, which enters the list of fields in the deployment descriptor. Container-managed persistence has two advantages over bean-managed persistence. First, entity beans with container-managed persistence require less code.
Second, because the beans don't contain the database access calls, the code is independent of any particular data store , such as a relational database. However, container-managed persistence has several limitations. Container-Managed Persistence limitations The implementation of container-managed persistence for entity beans does not provide a full set of features for mapping objects to relational databases: The entity bean class may be mapped to only one table in the database.
A container-managed field may be mapped to only one column in the table.
When the container loads the container-managed fields from the underlying database, it loads all of them . If the amount of data loaded is large, this approach may be inefficient because a business method may not need all of the container-managed fields. If the container-managed fields of multiple entity beans map to the same data item in a database, and if these beans are invoked in the same transaction , they may see an inconsistent view of the data item. The Application Deployment Tool generates SQL statements for the ejbCreate, ejbRemove, ejbLoad, and ejbStore methods. You may modify only the table and column names of these
SQL statements. You may not modify the number and order of the question marks, which are
place holders for the input parameters. You cannot call stored procedures in the generated SQL statements.
In the "Create Table" SQL statement, you may change the SQL type of a table column provided that the SQL type is compatible with its corresponding instance variable. The table and column names in all of the SQL statements must be consistent.