: A Persistent Employee Registry in Java

Generation Denso QR Bar Code in Java : A Persistent Employee Registry

From our simple Employee entity defined earlier, we can use the EntityManager facilities to perform CRUD (Create, Read, Update, Delete) operations and build a simple persistent registry of employees. The full example is available in greater detail in Appendix F.

Before we can take advantage of the EntityManager to flush and synchronize our changes with the database, we must set up a transactional context within which our code can

run. Because we re not going to delve into the full features of transactions until later, let s define a simple abstraction that marks the beginning and end of the transactional context.

public interface TxWrappingLocalBusiness { ** * Wraps the specified tasks in a new Transaction * * @param task * @throws IllegalArgumentException If no tasks are specified * @throws TaskExecutionException If an error occurred in invoking * {@link Callable#call()} */ void wrapInTx(Callable< >... tasks) throws IllegalArgumentException, TaskExecutionException; }

From here we can construct simple java.util.concurrent.Callable implementations that encapsulate our JPA operations, and these will all run within a transaction that starts and ends with the invocation to wrapInTx. Let s assume we have an instance called txWrapper that implements TxWrappingLocalBusiness for us.

Persisting an entity is the act of inserting it within a database. We persist entities that have not yet been created in the database. To create an entity, we first allocate an instance of it, set its properties, and wire up any relationships it might have with other objects. In other words, we initialize an entity bean just as we would any other Java object. Once we ve done this, we can then interact with the entity manager service by calling the EntityManager.persist() method:

// Execute the addition of the employees, and conditional checks, // in the context of a Transaction txWrapper.wrapInTx(new Callable<Void>() { @Override public Void call() throws Exception { // Create a few plain instances final Employee dave = new Employee(ID_DAVE, NAME_DAVE); final Employee josh = new Employee(ID_JOSH, NAME_JOSH); final Employee rick = new Employee(ID_RICK, NAME_RICK); // Get the EntityManager from our test hook final EntityManager em = emHook.getEntityManager(); // Now first check if any employees are found in the underlying persistent // storage (shouldn't be) Assert .assertNull("Employees should not have been added to the EM yet", em.find(Employee.class, ID_DAVE));

// Check if the object is managed (shouldn't be) Assert.assertFalse("Employee should not be managed yet", em.contains(josh)); // Now persist the employees em.persist(dave); em.persist(josh); em.persist(rick); log.info("Added: " + rick + dave + josh); // The employees should be managed now Assert.assertTrue( "Employee should be managed now, after call to persist", em.contains(josh)); // Return return null;

});

}

When this method is called, the entity manager queues the Employee instances for insertion into the database, and the objects become managed. When the actual insertion happens depends on a few variables. If persist() is called within a transaction, the insert may happen immediately, or it may be queued until the end of the transaction, depending on the flush mode (described later in this chapter). You can always force the insertion manually within a transaction by calling the EntityManager.flush() method. You may call persist() outside of a transaction only if the entity manager is an EXTENDED persistence context. When you call persist() outside of a transaction with an EXTENDED persistence context, the insert is queued until the persistence context is associated with a transaction. An injected extended persistence context is automatically associated with a JTA transaction by the EJB container. For other extended contexts created manually with the EntityManagerFactory API, you must call EntityManager.joinTransaction() to perform the transaction association. If the entity has any relationships with other entities, these entities may also be created within the database if you have the appropriate cascade policies set up. Cascading and relationships are discussed in detail in 11. Java Persistence can also be configured to automatically generate a primary key when the persist() method is invoked through the use of the @GeneratedValue annotation atop the primary key field or setter. So, in the previous example, if we had auto key generation enabled, we could view the generated key after the persist() method completed. The persist() method throws an IllegalArgumentException if its parameter is not an entity type. TransactionRequiredException is thrown if this method is invoked on a transaction-scoped persistence context. However, if the entity manager is an extended persistence context, it is legal to call persist() outside of a transaction scope; the insert is queued until the persistence context interacts with a transaction.