Ejb6

Application-managed Entity Manager To allow for situations where we do not require the services offered by an EJB 3 container but would like to use the persistence model, the Java Persistence API provides application-managed entity managers. Typically a Java application, such as a Swing program, would make use of an application-managed entity manager. These standalone Java applications are referred to as Java SE (Standard Edition) applications. Application-managed entity managers can also be used in servlets.. With application-managed entity managers, the application manages the entity manager's lifecycle. Container-managed entity managers normally use JTA (Java Transaction API) transactions and while it is possible to use JTA transactions with application-managed entity managers, normally resource-local transactions are used. An API, the EntityTransaction interface, is provided for resource-local transactions. This interface provides methods for beginning, committing and rolling back transactions. JTA transactions are discussed in more detail in Chapter 7. Whenever an application uses a container-managed entity manager it injects an EntityManager instance using the @PersistenceContext annotation as follows: @PersistenceContext(unitName="BankService") private EntityManager em ;

We have seen several examples of this. Behind the scenes the container creates an EntityManagerFactory; this factory is used to create EntityManager instances whenever the @PersistenceContext annotation is used. Finally the container, and not the application, closes both the EntityManager and EntityManagerFactory. In the case of application-managed entity managers we need to explicitly create an EntityManagerFactory. We also need to explicitly close both the EntityManager and EntityManagerFactory. Let's look at an example The listing below shows a Java application, BankClient, which adds a customer to the database and then retrieves the same customer. The program uses the same Customer entity we have seen in previous chapters. public class BankClient { public static void main(String[] args) { EntityManagerFactory emf = Persistence.createEntityManagerFactory( "BankService"); EntityManager em = emf.createEntityManager(); int custId = 0 String firstName = null; String lastName = null; try { custId = Integer.parseInt(args[0]); firstName = args[1]; lastName = args[2]; } catch (Exception e) { System.err.println( "Invalid arguments entered, try again"); System.exit(0); }

addCustomer(em, custId, firstName, lastName); Customer cust = em.find(Customer.class, custId); System.out.println(cust); em.close(); emf.close(); } private static void addCustomer(EntityManager em, int custId, String firstName, String lastName) { EntityTransaction trans = em.getTransaction(); trans.begin(); Customer cust = new Customer(); cust.setId(custId); cust.setFirstname(firstName); cust.setLastname(lastName); em.persist(cust); trans.commit(); } }

Note that the application first creates a reference to the EntityManagerFactory associated with our persistence unit, BankService. We then use the EntityManagerFactory.createEntityManager() method to create an instance of the EntityManager: EntityManagerFactory emf = Persistence.createEntityManagerFactory( "BankService"); EntityManager em = emf.createEntityManager(); Since adding a new customer to the database is a transactional operation, we need to explicitly use the EntityTransaction interface. The EntityTransaction.getTransaction() method returns the interface: EntityTransaction trans = em.getTransaction(); We start a transaction with the EntityTransaction.begin() method and after persisting our new customer entity with the EntityManager.persist() method, we commit the transaction with the EntityTransaction.commit() method. The EntityTransaction interface also has rollback() and isActive() methods. These are respectively for rolling back a transaction and for determining whether a transaction is in progress. We need to modify the persistence.xml file to indicate that we are using resource-local transactions in a Java SE environment. <?xml version="1.0" encoding="UTF-8"?> <persistence xmlns=http://java.sun.com/xml/ns/persistence version="1.0">

<persistence-unit name="BankService" transaction-type="RESOURCE_LOCAL"> <class>ejb30.entity.Customer</class> <properties> <property name="toplink.jdbc.driver" value="org.apache.derby.jdbc.ClientDriver"/> <property name="toplink.jdbc.url" value="jdbc:derby://localhost:1527/sun-appserv-samples"/> <property name="toplink.jdbc.user" value="app"/> <property name="toplink.jdbc.password" value="app"/> </properties> </persistence-unit> </persistence>

Note that we have specified the transaction-type as RESOURCE_LOCAL. The <class> element provides the name of a class which the persistence provider adds to its set of managed classes. We are not required to do this in a container-managed environment as the container obtains the managed classes from the JAR file containing the persistence.xml file The <properties> element specifies vendor specific properties. The EJB 3 reference implementation uses Toplink as the persistence provider, so the above <properties> elements are all Toplink specific. toplink.jdbc.driver is the name of the JDBC driver. If we are using the Derby database the driver is org.apache.derby.jdbc.ClientDriver. toplink.jdbc.url is the JDBC connection URL to the database. For the Derby database embedded within GlassFish, this value is jdbc:derby://localhost:1527/sun-appserv-samples. sun-appserv-samples is the default database name when using the GlassFish embedded Derby database. toplink.jdbc.user and toplink.jdbc.password are the database user and password respectively. For the GlassFish embedded Derby database, the user and password both default to "app".

Entity Manager Merge In this and the remaining sections we discuss topics which are applicable to both container-managed and application-managed entity managers. However, our examples will assume a container-managed entity manager is being used. As we have seen, an entity becomes managed when we use the EntityManager.persist() method. At this point the entity is associated with a persistence context. While an entity is managed the state of the entity is automatically synchronized with the database by the entity manager. By default a persistence context is scoped to a transaction. When the transaction ends, the persistence context ends and the entity is no longer managed. An unmanaged entity is referred to as a detached entity and is no longer associated with a persistence context. This means that further changes to the entity are no longer reflected in the database. If an entity is passed by value, through the remote interface to another application tier for example, then it also becomes detached. A typical scenario in 3-tier applications is to create a remote instance of an entity in the web-tier, possibly modify the entity, and then update the database with the new entity values. To cater for the above scenario, the EntityManager.merge() method is provided. This synchronizes the state of a detached entity with the database. As an example, suppose we have a stateless session bean, BankServiceBean, as listed below:

@Stateless public class BankServiceBean implements BankService { @PersistenceContext(unitName="BankService") private EntityManager em; public Customer findCustomer(int custId) { return ((Customer) em.find(Customer.class, custId)); } public void addCustomer(int custId, String firstName, String lastName) { Customer cust = new Customer(); cust.setId(custId); cust.setFirstName(firstName); cust.setLastName(lastName); em.persist(cust); } public void updateCustomer(Customer cust) { Customer mergedCust = em.merge(cust) ; } }

A new method is updateCustomer(). This takes a detached Customer entity, cust, as an argument. The EntityManager.merge() method takes the detached entity as an argument and creates a managed entity, mergedCust. From this point on any setter methods on mergedCust will be synchronized with the database. The code fragment below shows how a remote client first adds a customer to the database then creates a remote Customer object by invoking the BankService.findCustomer() method. After modifying this object the BankService.updateCustomer() method is invoked. updateCustomer() performs the merge. @EJB private static BankService bank; bank.addCustomer(custId, firstName, lastName); Customer cust = bank.findCustomer(custId); cust.setFirstName("Michael"); bank.updateCustomer(cust)

Entity Manager Methods In this section we look at some more EntityManager methods. remove() The remove() method flags an entity for removal from the database. Note that the entity must be a managed entity. The removal need not take place immediately. Removal occurs whenever the EntityManager decides to synchronize, or flush , the persistence context with the database. Typically this occurs when a transaction is committed. The code below shows a BankServiceBean method, removeCustomer(), which would be invoked in order to remove a Customer entity public void removeCustomer(Customer cust) { Customer mergedCust = em.merge(cust); em.remove(mergedCust); } the method first merges an entity to ensure it is managed before removing it.

contains() The contains() method is used to check whether an entity is managed in the current persistence context. It returns a boolean which is set to true if the entity is managed, otherwise it set to false. For example: if (em.contains(cust)) { System.out.println("cust is managed"); } flush() Flushing, or synchronizing a persistence context with the database, is usually under the control of the entity manager. Typically flushing occurs at transaction commit time, although the entity manager may flush at other times, such as before query execution, if it sees fit. The flush() method enables the application to force synchronization of the persistence context with the database. The syntax is simply: em.flush() setFlushMode() By default, whenever a query is executed within a transaction the entity manager ensures that any updates to the database are included in the query results. Typically this is done by flushing before query execution. This behavior is known as a flush mode of AUTO. A flush mode of COMMIT will cause flushing to occur only at transaction commit.

A COMMIT flush mode will improve query performance as there are fewer calls to the database. This mode would be used if we know the query is not affected by potential database updates. The flush mode can be set on the entity manager using the setFlushMode() method. This mode will then apply to all queries. The setFlushMode() method expects an argument of either FlushModeType.COMMIT or FlushModeType.AUTO. Recall FlushModeType.AUTO is the default behavior. For example em.setFlushMode(FlushModeType.COMMIT); We can also set the flush mode on a query object on a per query basis. For example: Query query = em.createQuery( "SELECT c FROM Customer c WHERE c.id = ?1") .setParameter(1, custId) ; query.setFlushMode(FlushModeType.AUTO); The query flush mode will override any entity manager flush mode . refresh() The refresh() method is used where we want to ensure that any change to the database is synchronized with a managed entity. For example: em.refresh(mergedCust); Note that mergedCust must be a managed entity. The refresh() method is more likely to be used in a long running transaction.

clear() The clear() method clears the persistence context. This causes all managed entities to become detached. The syntax is simply: em.clear() Note that any updates to entities will not be flushed to the database by the clear() method. Cascade Operations Cascading can occur whenever we have relationships between entities. For example, there is a one-to-one relationship between the Customer and Referee entities in our application. By allowing a persist operation to cascade, whenever we persist a Customer entity, the associated Referee entity is automatically persisted. There is no need to persist the Referee entity in a separate operation. By allowing a remove operation to cascade, whenever we remove a Customer entity, the associated Referee is automatically removed. Cacading can occur for one-to-one, one-to-many, many-to-one, and many-to-many relationships. Cascading is possible for persist, remove, merge, and refresh operations. There is no default cascading behavior for any operation and for any relationship.

persist To cascade a persist operation, set the cascade element of the relationship annotation to CascadeType.PERSIST. For example, we could cascade a persist from the Customer to the Referee entity by modifying the @OneToOne annotation within the Customer entity as follows: @OneToOne( cascade=CascadeType.PERSIST ) public Referee getReferee() { return referee; } If we wanted to cascade a persist from a Referee entity to a Customer entity we would need to set the cascade option from within the Referee entity. remove To cascade a remove operation set the cascade element of the relationship annotation to CascadeType.REMOVE. The cascade remove only applies to one-to-one and one-to-many relationships. For example, we could cascade a remove from the Customer to associated Account entities as follows: @OneToMany(fetch=EAGER, cascade=CascadeType.REMOVE ) public Collection<Account> getAccounts() { return accounts; } As a result, whenever a Customer entity is removed, associated Account entities are automatically removed.

A cascade remove should be used with caution. In the above example it may make sense for Account entities to exist on their own, or be part of a relationship other than the Customer-Account one. merge To cascade a merge operation set the cascade element of the relationship annotation to CascadeType.MERGE. For example, we could cascade a merge from the Customer to associated Account entities as follows: @OneToMany(fetch=EAGER, cascade=CascadeType.MERGE ) public Collection<Account> getAccounts() { return accounts; } In this example, assume we detach a Customer entity, update the detached Customer and its associated Account entities and then merge the Customer entity. Without a cascade, any updating of an Account entity will be lost after the merge, unless the Account entity is also merged. With a cascade merge we only need to merge the Customer entity to have the associated Account entities merged as well. refresh To cascade a refresh operation, set the cascade element of the relationship annotation to CascadeType.REFRESH. For example, we could cascade a refresh from the Customer to associated Account entities as follows: @OneToMany(fetch=EAGER, cascade=CascadeType.REFRESH ) public Collection<Account> getAccounts() { return accounts; } This has the effect that when we refresh a managed Customer entity, associated Account entities are automatically refreshed.

all We can specify more than one cascade type to a relationship annotation by simply listing the cascade types as follows: @OneToMany(fetch=EAGER, cascade={CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REMOVE} ) public Collection<Account> getAccounts() { return accounts; } If we want to specify all four cascade types (persist, merge, remove and refresh), we can use the ALL value as follows: @OneToMany(fetch=EAGER, cascade=CasCadeType.ALL ) public Collection<Account> getAccounts() { return accounts; }

Extended Persistence Context So far, all of our examples have used transaction scoped entity managers. Whenever a new transaction started, a new persistence context was created. This was true for both container-managed and application-managed entity managers. In the case of application-managed entity managers, as we have seen, the application explicitly starts and ends the transaction. In the case of container-managed entity managers, by default a transaction starts when a remote client invokes a session bean method. The transaction ends when that session bean method ends. This is the default transaction behavior and as we shall see in Chapter 7, it is possible to configure transaction start and end points to some extent. Transaction scoped entity managers have a rather restrictive effect when it comes to applications using stateful session beans. Suppose we have a remote client, BankClient, which invokes three methods in turn on a stateful session bean, BankService. The first method adds a new Customer entity, the second and third methods update the customers' first and last name respectively. The code fragment from BankClient will look like: @EJB private static BankService bank; bank.addCustomer(custId, firstName, lastName); bank.updateFirstName("Michael"); bank.updateLastName("Angelo");

Note that because BankServiceBean is a stateful session bean, the state of the Customer entity created by the addCustomer() method is saved. Consequently the updateFirstName() and updateLastName() methods can access this Customer entity. A code fragment from BankServiceBean() is shown below: @Stateful public class BankServiceBean implements BankService { @PersistenceContext(unitName="BankService") private EntityManager em; private Customer cust; public void addCustomer(int custId, String firstName, String lastName) { cust = new Customer(); cust.setId(custId); cust.setFirstName(firstName); cust.setLastName(lastName); em.persist(cust); } public void updateFirstName(String firstName) { cust.setFirstName(firstName); Customer mergedCust = em.merge(cust); } public void updateLastName(String lastName) { cust.setLastName(lastName); Customer mergedCust = em.merge(cust); }

Because each method invocation is a separate transaction, a new persistence context is created at the start of each method call and is closed as soon as the method ends. Consequently the Customer entity cust created by the addCustomer() method becomes detached as soon as addCustomer() finishes. This means the updateFirstName() and updateLastName() methods must perform a merge operation in order to create a managed entity: Customer mergedCust = em.merge(cust); To enable a persistence context to span more than one transaction, EJB 3 provides a container-managed Extended Persistence context . This only applies to stateful session beans. The persistence context starts as soon as we perform a JNDI look-up or dependency injection on the stateful session bean. The persistence context lasts until the stateful session bean is destroyed, usually by a @Remove method of the bean. As a result, entities created by a session bean method remain managed throughout the life of the session bean and there is no need to perform any merge operations. To indicate that a persistence context is extended we add the type=PersistenceContextType.EXTENDED element to the @PersistenceContext annotation: @PersistenceContext(unitName="BankService", type=PersistenceContextType.EXTENDED) We can now modify the updateFirstName() and updateLastName() methods, removing the merge step: public void updateFirstName(String firstName) { cust.setFirstName(firstName); } public void updateLastName(String lastName) { cust.setLastName(lastName); }

Entity LifeCycle Callback Methods We saw session bean callback methods in Chapter 2. Callback methods are also provided for events in an entity's lifecycle. The callback events are: PostLoad PrePersist PostPersist PreRemove PostRemove PreUpdate PostUpdate An entity can define a method corresponding to one or more of these events by prefixing the method with a corresponding annotation. So a PostLoad method would be prefixed by @PostLoad and so on. The PostLoad callback method is invoked by the entity manager after an entity has been loaded by a query, or after a refresh operation. For example, in the Customer entity we could add a PostLoad method as follows: public void postLoad(){ System.out.println("customer.postLoad method invoked"); }

Note we do not have to name our method postLoad(). Any name is acceptable provided the method returns a void, has no arguments and does not throw a checked exception. This applies to any of the entity lifecycle callback methods. The PrePersist event occurs immediately after a persist() method is invoked, but before any database insert. A PrePersist event also occurs if a merge operation causes the creation of a new, managed entity instance. If an entity is persisted as a result of a cascade then the PrePersist event also occurs. The PostPersist event occurs immediately after a database insert. This usually occurs at transaction commit time, but can occur after an explicit flush or if the entity manager decides to flush. In the latter two cases a rollback could still occur after a PostPersist. The PreRemove event occurs immediately after a remove method is invoked but before any database delete. If an entity is removed as a result of a cascade then the PreRemove event also occurs. The PostRemove event occurs immediately after a database delete. This usually occurs at transaction commit time, but can occur after an explicit flush or if the entity manager decides to flush. In the latter two cases a rollback could still occur after a PostRemove. A PreUpdate event occurs immediately before a database update. A database update can occur when an entity is updated or at transaction commit time, but can also occur after an explicit flush or if the entity manager decides to flush. A PostUpdate event occurs immediately after a database update. An entity can have callback methods for any number of lifecycle events, but for any one lifecycle event there can be at most only one callback method. However the same callback method can be invoked for two or more lifecycle events.

Entity Listeners An alternative to placing entity lifecycle callback methods in the entity itself is to place the methods in one or more separate classes. These classes are known as entity listeners . The code below is an example of an entity listener: public class CustomerListener{ public CustomerListener() {} @PostLoad public void postLoad(Customer cust){ System.out.println( "custListener.postLoad method invoked " + cust.getId() ); } @PrePersist public void prePersist(Customer cust){

System.out.println( "custListener.prePersist method invoked " + cust.getId() ); } @PostPersist public void postPersist(Customer cust){ System.out.println( "custListener.postPersist method invoked " + cust.getId() ); } @PreUpdate public void preUpdate(Customer cust){ System.out.println( "custListener.preUpdate method invoked " + cust.getId() );

} @PostUpdate public void postUpdate(Customer cust){ System.out.println( "custListener.postUpdate method invoked " + cust.getId() ); } @PreRemove public void preRemove(Customer cust){ System.out.println( "custListener.preRemove method invoked " + cust.getId() ); } @PostRemove public void postRemove(Customer cust){ System.out.println( "custListener.postRemove method invoked" + cust.getId() ); } } Note that the lifecycle methods within an entity listener take an object as an argument. In our example, a Customer object is the argument; this indicates that the method will only be invoked by lifecycle events occurring on a Customer enti

We can construct a more general entity listener which applies to all entities. For example: public class BankListener{ public BankListener() {} @PrePersist public void prePersist(Object o){ System.out.println( "bankListener.prePersist method invoked " + o.getClass().getName() ); } } In this case because the argument is of type Object, the method will be invoked by a PrePersist event on any entity. To indicate which entity listeners are applicable for a given entity, we need to add the @EntityListeners annotation in the entity itself. For example, the code below is a fragment from the Customer entity: @Entity @EntityListeners({CustomerListener.class, BankListener.class}) public class Customer implements Serializable { @PrePersist public void prePersist(){ System.out.println( “ customer.prePersist method invoked”); } ... }

In our example both CustomerListener and BankListener are applicable. Note that the entity itself can still have a lifecycle method present. Lifecycle methods are executed in the order in which the entity listeners are listed in the @EntityListeners annotation followed by any lifecycle methods in the entity itself. In our example the @PrePersist method in CustomerListener will be executed first, followed by the @PrePersist in BankListener and finally the @PrePersist method in Customer will be executed last A lifecycle callback method is applicable to inherited classes in an inheritance hierarchy. Suppose we have an Account entity with a @PrePersist method and a subclass SavingsAccount. Then the @PrePersist method will be invoked for a persist operations on SavingsAccount as well as Account itself. We could also define lifecycle callback methods in the inherited classes themselves. Lifecycle callback methods are executed in inheritance hierarchy order, base class before subclass. For example, a @PrePersist callback method in Account will be executed before any @PrePersist method in SavingsAccount. Entity listener classes also apply to inherited classes in an inheritance hierarchy. Suppose we have an Account entity with an associated entity listener class, AccountListener.class, as follows:

public class AccountListener { @PrePersist protected void prePersistAccount(Object account) {...} } Suppose SavingsAccount is a subclass of Account with an associated entity listener class, SavingsAccountListener.class, as follows: public class SavingsAccountListener { @PrePersist protected void prePersistSavingsAccount( Object savingsAccount) {...} } A persist operation on SavingsAccount will cause the prePersistAccount() and prePersistSavingsAccount() methods to be executed in order.

Ejb6

More Related Content

What's hot

Similar to Ejb6

More from patinijava

Recently uploaded

Ejb6