This part of the article will concentrate on more complex object-relational mappings. Java Persistence has mappings for JDBC BLOBS and CLOBS, serializable objects and embeddable objects. The following will go through each of the mapping one by one.
1. The persistence provider will assume that every nontransient property in your entity bean class is persistent. If you do not want a property to be persistent, you can mark the field or the setter/getter methods with @javax.persistence.Transient annotation depending on the access type.
2. The @javax.persistence.Basic is the most primitive type of O/R mapping that covers all primitives and its wrapper types. The annotation has two interesting attributes: fetch() and optional().
The fetch() attribute defines that strategy for fetching data from the database, which takes two values: EAGER and LAZY. If the FetchType is LAZY, that particular property is not initialized until you actually access the field. The EAGER fetch strategy is the default and it is the opposite of LAZY.
In this part of the article, we concentrate on creating entity bean.
Java Persistence requires an entity bean to have two pieces of metadata: @javax.persistence.Entity to tell the EJB container to map the class to the database table and @javax.persistence.Id, the primary key of the table. By default, the persistence provider assumes name-to-name and type-to-type mapping of the fields to database columns. The table name is also the same as the unqualified name of the entity bean class unless specified by the name() attribute.
There are two ways of applying @Id annotation: Java Bean style - mark on setter and getter methods or on each field. In either case, the provider will assume the following methods or fields are also persistent properties. As usual, XML mapping is also available if you prefer.
An EntityManager can be injected directly into an EJB using the @javax.persistence.PersistenceContext annotation. By default, a transaction-scoped persistence context is injected. You can override the default with type() attribute. When the transaction is completed, the EJB container will perform the cleanup. The extended entity manager can only be injected into a stateful session bean.
As mentioned in part 1 of the article, the EntityManager is the central service for all persistence actions. The persistence actions can be summarized as follow:
The javax.persistence.EntityManager is the central service for all persistence actions. Entity beans are plain Java objects that interact with EntityManager to make them persistent. EntityManager has the following role:
- manages the object-relational mapping between a fixed set of entity classes and the underlying data source.
- provides APIs for creating queries, finding objects, synchronizing objects and inserting objects into the database.
- provides caching and manage the interaction between an entity and transactional services.
- tracks state changes to the entity bean.
EntityManager manages persistence context, a set of entity bean instances. When the persistence context is closed, all managed entity objects become detached and are unmanaged.
Message-driven beans are specially designed to consume JMS messages. It is not advisable to “force” a session bean into this role. They are stateless, server-side, transaction-aware components for processing JMS messages. The EJB container manages transactions, security, resources, concurrency and message acknowledgment for MDBs.
All EJB 3.0 containers must support JMS provider and other providers through JCA (for Connector-based MDBs). In order to send a JMS message, we need a connection to the JMS provider and a destination address for the message. Using a connection factory javax.jms.ConnectionFactory similar to javax.sql.DataSource, you can create a connection to the JMS provider.
Each stateful session bean is dedicated to one client for the life of the bean instance. Stateful session beans are primarily used to encapsulate and manage task flow on behalf of the client - they manage the interactions of other beans for the client.
Stateful session beans do not use instance pooling. Each stateful session bean must be passivated before it is evicted from memory in order to preserve the conversational state of the instance. It must then be activated when the bean becomes active again. The process achieves certain level of resource pooling but it is different from stateless session bean’s instance pooling.
The lifecycle of a stateful session bean that do not implement javax.ejb.SessionSynchronization interface can be summarized as follow:
Stateless session beans are lightweight and fast and require no passivation and activation. Therefore, they are particularly suitable for any activity that can be accomplished in one method call, such as report generation, credit card validation and batch processing.
Stateless session beans maintain no state from one method invocation to the next. They have longer timeout period because they are not dedicated to one client. A timeout or removal operation invalidates the EJB object reference but may not destroy the bean instance. A client can also explicitly remove a stateless session bean by invoking a business interface annotated as @javax.ejb.Remove.
Stateless session beans have only two states - Does not Exist and Method-Ready Pool. The actions on the transition of both states include
Class.newInstance()- injections
- (callback)
@javax.annotation.PostConstructor<post-construct>inejb-jar.xml - (callback)
@javax.annotation.PreDestroyor<pre-destroy>inejb-jar.xml
I will be writing a series of articles related to EJB 3.0 in preparation for my SCBCD exam. The main objective is to keep updating the site while studying intensively for one month. The notes are prepared by reading through Enterprise JavaBeans 3.0, Fifth Edition by Bill Burke and Richard Monson-Haefel.
Entity Bean
In EJB 3.0, persistence has been spun off from EJB to its own specification called Java Persistence API. The API defines a way to map plain old Java objects (POJOs) to a database. These plain old Java objects are called entity beans.
The Java Persistence API also defines EJB QL that is tailored to work with Java objects rather than a raw relational schema. Entity beans are different from EJB session beans in that they are POJOs. They do not have a remote or local interface and can be accessed only as POJOs.
In order to “make” a POJO class as an entity bean class, you need to tag the class with @javax.persistence.Entity annotation and have at least one field or getter method that is designated as the primary key using @javax.persistence.Id annotation. All access to an entity goes through EntityManager persistence service that provides query API and life cycle methods.
Continue reading ‘SCBCD Notes: EJB & Java Persistence Architecture’