Why entity beans are called transactional resources

See later in this chapter for EAR packaging and deployment. The properties element in the persistence. Please refer to the Hibernate and Hibernate EntityManager documentation for more details.

Here we will just give an example to set the SQL dialect of the persistence engine to HSQL, and to create tables from the entity beans when the application starts and drop those tables when the application stops. Then call getInstance to get a new Session object with the new properties.

Create an Address for each recipient of the message:. In the setFrom method, the value of the attribute is obtained implicitly from the mail. If this property is absent, the system property user. You must put your code in a try block and catch these exceptions. To reply to a message, you must create a new message from the original by using the reply method.

The reply method copies the from or reply-to header to the new recipient. The method also takes a Boolean parameter indicating whether to reply to only the sender false or reply to all the recipients true. The following is an example of replying only to the sender:. To set the reply-to address when sending a message, use the setReplyTo method. To forward a message to a new recipient, you must construct a new message and then populate its parts. An e-mail message can be made up of multiple parts.

Each part is a MimeBodyPart , and the different body parts are combined into a container called a MimeMultipart. To forward a message, you create one part for the text of your message and a second part with the message to forward, and then combine the two into a multipart message.

Then you add the multipart message to a properly addressed message and send it. Attachments are resources that are associated with a mail message, and are usually kept outside of that message; for example, a text file, a Word document, or an image. A message with attachments is represented as a MIME multipart message in which the first part is the main body of the message and the other parts are the attachments.

The FileDataSource is part of the Java Activation Framework, and its constructor accepts a String that indicates the full filename on the disk.

New e-mail systems support HTML and image content. Situations sometimes arise in which you need to send a message in a language other than a Latin-based script char set. This is common in internationalization i18n efforts of enterprise applications. To accomplish this, you must set the message to the right locale for the language. You might need to check the Web server documentation before sending messages using different char sets.

Reading mail messages involves fetching the messages from the message store. Each message in the preceding snippet is processed according to your business requirements. You must flag the message with the Flags. The following code snippet demonstrates how to delete a message:. The setFlag method does not delete the message, it only marks the message for deletion. The close method with the true parameter value is where messages are deleted or expunged. The servlet component in the Web tier represents the controller, which acts as a client to the EJB tier.

The student interacts with the EmailerServlet using the emailer. The EmailerServlet , on behalf of the client, relays the request to the Emailer EJB, which sends the e-mail to the recipient through the e-mail server. Develop the EJB tier components. You need to develop only one component: the Emailer session bean. Develop the Web tier components. You need to develop the EmailerServlet.

Package the modules into an application EAR file. Deploy and run the application on each server. The following sections give you more details about performing each of the steps mentioned in this list. As usual, the full application code listing, and scripts for compiling and deploying into the WebLogic Server and JBoss server environments can be downloaded from our Web site. The main business method is the sendMail method, which sends e-mail messages to students.

As you learned on previous days, we need to develop the remote interface, home interface, and the bean class. The following listings provide the code for these components. Listing For large applications, all the components of the EJB tiers are packaged into one JAR file, along with its deployment descriptors. For our example today, you need to package only one component. To build the example for the appropriate application server, you need to be in the Day20 directory, and then run the build script provided for this server.

This will create a build subdirectory that contains all the compiled code. The script will then package the EJBs with the deployment descriptor see Listing You must provide a server-specific deployment descriptor for each application server; they are included in your download jboss. Students first interact with the servlet through the HTML form discussed in the next section , and requests are relayed back to the EJB tier to execute the required business logic.

You must also provide a server-specific Web deployment descriptor. The jboss-web. The script provided for each server will create a web subdirectory that contains all the compiled code. It will then package the EmailerServlet component and the deployment descriptor web. The modules created in the previous sections—one for the Web tier and one for the EJB tier—can be combined into an application file EAR file.

For the sake of convenience, both scripts are also combined into one script to package the application into an EAR file. The script for JBoss is included in the downloaded files. In our example, you create a mail Session by specifying the default mail user, mail host, transport, and store protocols in the Administration Console so that components that use JavaMail do not have to set these properties see Figure Applications that are heavy e-mail users benefit because WebLogic Server creates a single Session object and makes it available via JNDI to any component that needs it.

Click Create a New Mail Session. In the Name field, enter a name for the new session. Enter MailSession. Use ursMailSession. Your code uses this string to look up the javax. The code that you write for the entity bean does not include these calls.

With bean-managed persistence, you must write the database access code and include it in the bean. Shared Access—Throughout its life cycle, an entity bean instance can support multiple clients, although not at the same time. Because the clients might want to change the same data, it is important that entity beans work within transactions. Typically, the EJB container provides transaction management. In this case, you specify the transaction attributes in the bean's ejb-jar.

You do not have to code the transaction boundaries in the bean—the container marks the boundaries for you. For information about transaction management, see Transaction Design and Management Options. Primary Key—Each entity bean has a unique object identifier. A customer entity bean, for example, might be identified by a customer number.

The unique identifier, or primary key, enables the client to locate a particular entity bean. Relationships—Like a table in a relational database, an entity bean may be related to other entity beans. You implement relationships differently for entity beans with bean-managed persistence and for those with container-managed persistence. With bean-managed persistence, the code that you write implements the relationships.

But with container-managed persistence, the EJB container takes care of the relationships for you. For this reason, relationships in entity beans with container-managed persistence are often referred to as container-managed relationships. Read-only beans perform better than read-write beans, because they reduce the number of times that data is read from the database.

Some applications require the use of read-write entity beans—the choice depends on frequency of updates and data consistency requirements. Table provide key guidelines. You can tolerate some level of staleness in the data: it does not have to be completely up-to-date.

Example : A news feed. Users want to see the story as soon as it is in the database, but it is not updated transactionally. These sections describe approaches for choosing the entity bean implementation, based on your requirements for performance and data consistency. Read-only entity beans are recommended whenever stale data is tolerable—they are suitable for product catalogs and the majority of content within many applications.

Primary key-based reads are performed against a local entity cache that is invalided on a timer basis. Other queries are made against the database. Read-only entity beans perform three to four times faster than transactional entities. Read-write entity beans are recommended for applications that require high data consistency, for example, customer account maintenance.

All reads and writes are performed against the database. For read-mostly applications, characterized by frequent reads, and occasional updates for instance, a catalog —a combination of read-only and read-write beans that extend the read-only beans is suitable.

The read-only bean provides fast, weakly consistent reads, while the read-write bean provides strongly consistent writes. To avoid the overhead imposed by remote calls, avoid accessing remote EJB entity beans from client or servlet code. Instead, use a session bean, referred to as a facade , to contain complex interactions and reduce calls from Web applications to RMI objects. Alternatively, there are no disadvantages to accessing a local entity bean instance directly from the Web tier—it is preferable to do so than to use a facade.

Avoid the use of transfer objects, also referred to as value objects or helper classes. A transfer object is a serializable class within an EJB that groups related attributes, forming a composite value, which is used as the return type of a remote business method.

To optimize performance, accessing local entity instances is always preferable to the use of transfer objects. The messages may be sent by any J2EE component—an application client, another enterprise bean, or a Web component—or by non-J2EE applications. Configure the persistence management strategy—either container-managed or bean-managed—for an entity bean in the persistence-type element in ejb-jar. The bean does not contain code that accesses the database.

Instead, the EJB container generates the database access methods, based on information about the entity bean's persistent fields and relationships, in weblogic-cmp-jar. For more information, see "weblogic-cmp-jar. Reduced programming effort—You do not write methods to perform database access for a CMP bean. The EJB container generates the methods automatically.

De-coupling physical database details from business logic makes a bean logically independent of the associated database. If you implement a modified database design, or change to a different database server, you do not have to modify bean code.

You can redeploy the bean on a different J2EE application server without modifying or recompiling bean code. However, some application requirements cannot be satisfied by CMP beans. Define the type of the primary key to be a well-known type. The primary key variable that is declared within the bean class must be declared as public.

This is an advanced method for defining a primary key and is discussed in "Defining the Entity Bean Primary Key in a Class".

Specify an auto-generated primary key: If you specify a java. For a simple CMP, you can define your primary key to be a well-known type by defining the data type of the primary key within the deployment descriptor. The employee example defines its primary key as a java. Integer and uses the employee number empNo as its primary key.

Once defined, the container creates a column in the entity bean table for the primary key and maps the primary key defined in the deployment descriptor to this column. Within the orion-ejb-jar. In the following orion-ejb-jar. This enables the container to manage the primary key fields. Be declared within the bean class as public and restricted to be either primitive, serializable, or types that can be mapped to SQL types.

Within the primary key class, you implement a constructor for creating a primary key instance. Once the primary key class is defined in this manner, the container manages the class. Once defined, the container creates a column in the entity bean table for the primary key and maps the primary key class defined in the deployment descriptor to this column. The CMP fields are mapped in the orion-ejb-jar. Special mapping needs to happen if you have a complex primary key that contains a foreign key.

If you specify a java. Thus, the container auto-generates the primary key. Once defined, the container creates a column called autoid in the entity bean table for the primary key of type LONG.

The container uses random numbers for the primary key values. This is generated in the orion-ejb-jar. There are two methods for managing the persistent data within an entity bean: bean-managed BMP and container-managed persistence CMP. With CMP beans, the container manages the persistence—the bean deployment descriptor specifies how to map the data and where the data is stored.

With BMP beans, the logic for saving the data and where it is saved is programmed within designated methods. These methods are invoked by the container at the appropriate moments. In practical terms, the following table provides a definition for both types, and a summary of the programmatic and declarative differences between them:. For example, the ejbStore method must have logic in it to store the entity bean's data to the appropriate database. If it does not, the data can be lost.

You use ejbStore and ejbLoad for preparing the data before the commit or for manipulating the data after it is refreshed from the database. The container always invokes the ejbStore method right before the commit. In addition, it always invokes the ejbLoad method right after reinstating CMP data from the database. The EJB 2. An entity bean can be defined so as to have a relationship with other entity beans. You implement relationships differently for entity beans with bean-managed-persistence than those entity beans that utilize container-managed-persistence.

With bean-managed persistence, the code that you write implements the relationships. With container-managed persistence, the EJB container takes care of the relationships for you. For this reason, relationships in entity beans with container-managed persistence are often referred to as container-managed relationships. A relationship field is virtual and is defined in the enterprise bean class with access methods. Unlike a persistent field, a relationship field does not represent the bean's state.

Multiplicity in Container-Managed Relationships - There are four types of multiplicities all of which are supported by Oracle Application Server:. Many-to-One - Multiple instances of an entity bean may be related to a single instance of the other entity bean. This multiplicity is the opposite of one-to-many.

Direction in Container-Managed Relationships - The direction of a relationship may be either bi-directional or unidirectional. In a unidirectional relationship, only one entity bean has a relationship field that refers to the other.

In a bi-directional relationship, each entity bean has a relationship field that refers to the other bean. Through the relationship field, an entity bean's code can access its related object. If an entity bean has a relative field, then we often say that it "knows" about its related object. Oracle Application Server supports both unidirectional and bi-directional relationships between EJBs.

The direction of a relationship determines whether a query can navigate from one bean to another. You can manage the entity bean lifecycle through configuring pool sizes for your entity beans. This subject is covered in the following section:.

You can set the minimum and maximum number of the bean instance pool, which contains EJB implementation instances that currently do not have assigned state. While the bean instance is in pool state, it is generic and can be assigned to a wrapper instance. The max-instances attribute sets the maximum entity bean instances to be allowed in the pool. An entity bean is set to a pooled state if not associated with a wrapper instance.

Thus, it is generic. The default is 0, which means infinite.