NetBeans is a Java Integrated Development Environment, IDE, which enables fast
application development with the most adopted frameworks, technologies, and servers.

Different than other IDEs, NetBeans comes already pre-packaged with a wide range of
functionality out of the box, such as support for different frameworks, servers, databases,
and mobile development.

This book does require a minimal knowledge of Java platform, more specifically the
language ifself. But the book might as well be used by either beginners, who are trying to
dip their toes in new technology, or more experienced developers, who are trying to
switch from other IDEs but want to decrease their learning curve of a new environment.
NetBeans integrates so many different technologies, many of which are present in this
book, that it is beyond the scope of this book to cover all of them in depth. We provide
the reader with links and information where to go when further knowledge is required.

What This Book Covers

Chapter 1, NetBeans Head First introduces the developer to the basics of NetBeans by
creating basic Java projects and importing Eclipse or Maven projects.

Chapter 2, Basic IDE Usage covers the creation of packages, classes, and constructors, as
well as some usability feature.

Chapter 3, Designing Desktop GUI Applications goes through the process of creating
a desktop application, then connecting it to a database and even modifying it to look
more professional.

Chapter 4, JDBC and NetBeans helps the developer to setup NetBeans with the most
common database systems on the market and shows some of the functionality built-in to
NetBeans for handling SQL.

Chapter 5, Building Web Applications introduces the usage of web frameworks such as
JSF, Struts, and GWT.3

Chapter 6, Using JavaFX explains the basic of JavaFX application states and connecting
our JavaFX app to a web service interface.

Chapter 7, EJB Application goes through the process of building an EJB application
which supports JPA, stateless, and stateful beans and sharing a service through a web
service interface.

Chapter 8, Mobile Development teaches how to create your own CLDC or CDC
applications with the help of NetBeans Visual Mobile Designer.

Chapter 9, Java Refactoring lets NetBeans refactor your code to extract classes,
interfaces, encapsulate fields, and other options.

Chapter 10, Extending the IDE includes handy examples on how to create your own
panels and wizards so you can extend the functionality of the IDE.

Chapter 11, Profiling and Testing covers NetBeans Profiler, HTTP Monitor, and
integration with tools that analyze code quality and load generator.

Chapter 12, Version Control shows how to configure NetBeans to be used with the most
common version control systems on the market.

• Creating an EJB project
• Adding JPA support
• Creating Stateless Session Bean
• Creating Stateful Session Bean
• Sharing a service through Web Service
• Creating a Web Service client

Introduction

Enterprise Java Beans (EJB) is a framework of server-side components that encapsulates
business logic.

These components adhere to strict specifications on how they should behave. This ensures
that vendors who wish to implement EJB-compliant code must follow conventions, protocols,
and classes ensuring portability.

The EJB components are then deployed in EJB containers, also called application servers,
which manage persistence, transactions, and security on behalf of the developer.

If you wish to learn more about EJBs, visit http://jcp.org/en/jsr/detail?id=318 or

https://www.packtpub.com/developer-guide-for-ejb3/book.

For our EJB application to run, we will need the application servers.

Application servers are responsible for implementing the EJB specifications and creating the
perfect environment for our EJBs to run in.

Some of the capabilities supported by EJB and enforced by Application Servers are:

• Remote access
• Transactions
• Security Scalability

NetBeans 6.9, or higher, supports the new Java EE 6 platform, making it the only IDE so far
to bring the full power of EJB 3.1 to a simple IDE interface for easy development.

NetBeans makes it easy to develop an EJB application and deploy on different Application
Servers without the need to over-configure and mess with different configuration files. It’s
as easy as a project node right-click.

Creating EJB project

In this recipe, we will see how to create an EJB project using the wizards provided
by NetBeans.

Getting ready

It is required to have NetBeans with Java EE support installed to continue with this recipe.

If this particular NetBeans version is not available in your machine, then you can download it
from http://download.netbeans.org.

There are two application servers in this installation package, Apache Tomcat or GlassFish,
and either one can be chosen , but at least one is necessary.

In this recipe, we will use the GlassFish version that comes together with NetBeans 7.0
installation package.

How to do it…

1. Lets create a new project by either clicking File and then New Project, or by pressing
   Ctrl+Shift+N.
2. In the New Project window, in the categories side, choose Java Web and in Projects
   side, select WebApplication, then click Next.
3. In Name and Location, under Project Name, enter EJBApplication.
4. Tick the Use Dedicated Folder for Storing Libraries option box.
5. Now either type the folder path or select one by clicking on browse.
6. After choosing the folder, we can proceed by clicking Next.
7. In Server and Settings, under Server, choose GlassFish Server 3.1.
8. Tick Enable Contexts and Dependency Injection.
9. Leave the other values with their default values and click Finish.

The new project structure is created.

How it works…

NetBeans creates a complete file structure for our project.

It automatically configures the compiler and test libraries and creates the GlassFish
deployment descriptor.

The deployment descriptor filename specific for the GlassFish web server is
glassfish-web.xml.

This article is based on EJB3 in Action, Second Editionand the book will release on October 2011. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) ebooks and pbooks. MEAPs are sold exclusively through Manning.com. All print book purchases include an ebook free of charge. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information.

Stateless Session Beans

Introduction

Stateless session beans are probably the most common bean type used in an application. A stateless session bean doesn’t maintain a conversational state. This means that session beans tasks must be completed in a single method call. This does not limit a stateless session bean to containing only one method. To the contrary, a stateless session beans usually contain at least several closely related business methods. Of the session bean types, stateless session beans have the best performance characteristics. To understand why, take a close look at figure 1 that shows a high-level schematic of how stateless session clients typically use beans.

Figure 1 Complex stateless session bean application using nested transactions.

Stateless session beans are pooled. This means that, for each managed bean, the container keeps a certain number of bean instances ready in a pool. For each client request, an instance from the pool is quickly assigned to service the request. When the client finishes, the instance is returned to the pool for later reuse. This setup using a pool means that a small number of bean instances can service a relatively large number of clients. Don’t forget that these one-shot methods come with a number of services provided by the container.

In this article, you’ll learn about developing stateless session beans. We’ll start off by first looking at when stateless session beans are appropriate.

When to use stateless session beans

Session beans should be used to encapsulate business logic when you need dependency injection, transaction management, concurrency, security, remoting, scheduling, and support for interceptors. You specifically use a stateless session bean when the business logic you are implementing requires these services and can be performed within a single method call and the response is tailored for the client. This is an atomic piece of work that maintains no state after the method completes. The client may maintain state but the stateless session bean does not. To expound upon these basic guidelines we need to look to the prototypical session bean and then step back and look at the bigger picture.

To understand when to use stateless session beans let’s consider the prototypical use case that best exemplifies a stateless session bean. A stateless session bean should be a class with several methods that perform related operations such as managing users, updating account information, or managing bids. The related operations are all one shot; the bean doesn’t maintain any state after the method invocation is completed from the perspective of the client. The methods consume services such as database connections and possibly require security to enforce access control. The business operations performed by the bean are not static. They aren’t serving up the same data regardless of the client.

Stateless session beans may use other stateless session beans. These stateless session beans may interact with other database tables, resources, and have additional security requirements. Beans may and often will, use other beans. Figure 1 shows a design with multiple stateless session beans interacting with each other. Each of these beans uses transactions and also has security authorization requirements. A failure in the SAP Integration Bean should result in a rollback in the transaction in the Inventory and Bid Manager Beans. In this example, stateless session beans are joining transactions started by the parent stateless session bean and this is possibly being propagated down several levels. Thus, when trying to decide whether to make an object a stateless session bean, we have to approach it from the perspective of the services the methods require and how they are consumed by their clients.

We’ve just identified when to use stateless session beans but consideration should also be given to when not to use them. If you aren’t using any container services, such as remoting, injection, database resources, and so on, making a class a stateless session bean isn’t beneficial and overall application performance can suffer. If functionality in question is simply saving form data to a database, a JSF backing bean with an injected persistence context is more appropriate. In other words, now that you are familiar with stateless session beans, don’t turn every non-JPA POJO into a stateless session bean.

Stateless session bean pooling

As we see in figure 2 session beans are pooled by the container.

Figure 2 A singleton bean is instantiated once by the container. Each client accesses the same instance of a singleton session bean.

Whenever a request arrives for a bean, the container allocates a bean. When the stateless session bean’s method returns, the bean is placed back into the pool. Thus a bean is either servicing a request or waiting for a request in the pool. The pool serves two important functions. First, it ensures that there are objects ready to service a request when one arrives. Second, the pool bounds the number of instances that can be created. By keeping instances around to service requests, we minimize the amount of time it takes to begin servicing a request. If, every time a request arrived at the server, an object had to be instantiated and database connections established, a significant amount of time would be wasted. It would be analogous to going to a restaurant and waiting for the restaurant to run out and hire another waiter. At the opposite end of the spectrum, too many requests could flood the server and overwhelm available resources. If the container created another stateless session bean each time one was needed, the application could eventually exhaust resources. There is a limit to the number of database connections that can be open as well as the number of clients that can be serviced concurrently. Create too many objects fast and then toss them away, garbage collection will kick in and slow the application. Hence, limiting the size of the pool is a necessity.

The benefits of pooling stateless session beans should be obvious. You want to minimize the number of objects created to keep garbage collection from impacting the application while at the same time keeping some instances around to service requests. The act of balancing these two comes down to performance tuning. Each application container does performance tuning a little bit differently. As you develop and test your application, the tuning of this pool will be necessary. For instance, consider some of the pool settings available in the Glassfish server:

• Initial and minimum pool size—The minimum number of beans to appear in the pool. The default is 0.
• Maximum pool size—The maximum number of beans that can be present in the pool. The default is 32.
• Pool resize quantity—The number of beans to be removed when the pool idle timeout expires. The default is 8.
• Pool idle timeout—The maximum number of seconds that a bean can reside in the pool without servicing a request before it is released for garbage collection.

These are only a couple of the pool settings—there are many more. The parameters available to tune a container are container specific. Thus, the containers compete on scalability and performance-tuning features. The important thing to remember is that, if you are not using stateless session beans and are implementing your homegrown solution, you want have to implement your own pooling solution and then optimize its performance. As you can see, a stateless session bean is providing a significant amount of functionality. Implementing and testing business functionality is one thing; building an efficient pooling system and testing the algorithms is a separate matter.

The specification for stateless session beans refers to the pool as the Method-Ready Pool. An object in the method ready pool may have instance variables storing data—there is nothing to prevent the bean from doing this. However, given that there are numerous instances and that each method invocation is potentially and randomly a different client, member variables aren’t too useful unless they are used for internal purposes. For example, a method may load a complex object into memory and then store it in a member variable. The member variable can then be accessed from utility methods that are part of a call; you invoke method A, method A then invokes protected method B, and so on. This can be very dangerous because data could leak between method calls on a stateless session bean if precautions are not taken. Pooling stateless session beans is one of their key features.

Summary

We discussed the mechanics of stateless session beans—how to define them and how to pool them. We’ve explained when to use a stateless session bean.

This article is based on EJB3 in Action, Second Edition and the book will released on October 2011. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) ebooks and pbooks. MEAPs are sold exclusively through Manning.com. All print book purchases include an ebook free of charge. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information.

also read:

• EJB Interview Questions
• How to secure EJB applications?
• Using CDI with EJB 3.0
• J2EE Books

Using CDI with EJB 3.0

Introduction

CDI plays a vital role by providing robust, next-generation, annotation-driven dependency-injection to all Java EE components including EJB 3. In this article, we will show you some of the most common ways CDI is used with EJB 3—namely, as a more robust replacement to JSF-managed beans and complementing EJB with components that are not in the business tier and do not need to use EJB services directly.

Using CDI with JSF 2.0 and EJB 3.0

• Introduction to JSF

In order to see how CDI can be used as the superglue between JSF and EJB 3, let’s look at a bid service stateless session bean example. The bid service allows us to save bids into the database. Clearly, the add bid functionality would likely be used on a page that allows the bidder to place a bid on an item. If you are familiar with auction sites, this page could look something like figure 1.

Most of the page displays the details about the item, the bids, the seller, and the bidder such as the item title, description, highest bid, current bidders, seller information, and so on. The part we are most interested in is the text box to enter a bid amount and the button to place a new bid. The JSF 2 code for these two page elements will look like listing 1.

• EJB3 in Action, Second Edition

Listing 1 JSF page to add bid

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:ui="http://java.sun.com/jsf/facelets">
<h:body>
...
<h:form id="bid-form">
...
<h:inputText id="input-bid" value="#{bid.amount}"/> #1
...
<h:commandButton id="place-bid-button" #1
value="Place Bid!" #1
action="#{bidManager.placeBid}"/> #1
...
</h:form>
...
</h:body>
</html>

#1 Binding expressions to CDI managed beans

As you can see, both the input text field and the button are bound to the underlying beans using binding expressions (#1). The input text field is bound to the amount field of a bean named bid. This means that the text field displays the value of the bound bean field, and any value entered into the text field is automatically set into the bean field. The place-bid button is bound to the placeBid method of a bean named bidManager. This means that the bound method is automatically invoked when the button is clicked. Listing 2 shows code that the JSF page elements are bound to.

Listing 2 BidManager CDI managed bean

@Named #1
@RequestScoped #2
public class BidManager {
	@Inject #3
	private BidService bidService;
	@Inject #4
	@LoggedIn #4
	private User user;
	@Inject #5
	@SelectedItem #5
	private Item item;
	private Bid bid = Bid();
	@Produces #6
	@Named #6
	@RequestScoped #6
	public Bid getBid() {
		return bid;
	}
	public String placeBid() {
		bid.setBidder(user);
		bid.setItem(item);
		bidService.addBid(bid);
		return “bid_confirm.xhtml”;
	}
}

#1 Names bid manager CDI managed bean

#2 The bid manager is request scoped

#3 Injects bid service EJB

#4 Injects currently logged-in user

#5 Injects currently selected item

#6 Produces a request-scoped CDI managed bean named 'bid'

The bid manager component is not an EJB but simply a CDI-managed bean. This means that, other than life cycle, dependency injection, and context management, no enterprise services such as transaction management are available directly to the bid manager component. This is perfectly fine in this case since the bid manager simply acts as the glue between the JSF page and transactional EJB service tier.

As such, the bid manager is probably self-explanatory even with the various CDI annotations. The @Named CDI annotation (#1) on the bid manager names the component. By default, the component is named as the simplified class name in camel-case. In the case of the bid manager component, the name assigned will be ‘bidManager’. Naming a component is necessary in order to reference it from JSF EL. As you’ve seen, the BidManager.placeBid method is bound to the place bid button via an EL binding expression. The @RequestScoped CDI annotation (#2) specifies the scope of the bid manager. Because the bid manager is request scoped, the bean will be created when the JSF page is loaded and is destroyed when the user navigates to another page.

A number of other beans are injected into the bid manager component as dependencies. The first is the bid service stateless session bean (#3) we are already familiar with. The injections for the bidder (#4) and item (#5) are a bit more interesting. The @LoggedIn and @SelectedItem annotations are CDI user-defined qualifiers. Qualifiers are user-defined meta-data used to specify that you want a specific type of bean injected. For example, in case of injecting the user into the bid manager, we are specifying that we want a special kind of user—namely, the currently logged-in user. The code assumes that CDI has reference to a suitable User instance in some known accessible scope. Most likely, the User bean corresponding to the logged-in user is in the session scope and was placed there as part of the login process. Similarly, the bid manager code uses the @SelectedItem qualifier to specify that it depends on the item that the user has currently selected. The selected Item bean was likely placed into the request scope when the user clicked on the link to view the item details.

The @Produces, @RequestScoped, and @Named annotations (#6) placed on the getBid method are very interesting as well. As you may have guessed, the @Produces annotation is a key piece of functionality. The @Produces annotation tells CDI that the getBid method returns a Bid object that it should manage. The @Named and @RequestScoped annotations on the getBid method tells CDI that the returned Bid object should be named and it should be in the request scope. Because the bid object is named, it can be reference in EL just as we did in the JSF page. It is a JPA 2 entity that holds all bid data, including the bid amount that is bound by EL to the input text field on the JSF page. Because the bid manager creates and holds a reference to the bid object, it automatically has access to the bid data entered via the JSF page.

When the placeBid method is invoked in response to the button-click on the JSF page, the bid manager uses all the data it has reference to and properly populates the bid object. It then uses the bid service stateless session to have the bid into the database. Finally, the user is redirected to a page that confirms the bid.

That is all that we need to say about using CDI with EJB 3 at the presentation tier at the moment. CDI is used with EJB 3 in a number of other different ways, including at the persistence tier to implement DAOs. Let’s take a look at that next.

Using CDI with EJB 3.0 and JPA 2.0

In Java EE 5-based systems, the DAO layer is often implemented as EJB 3 beans. This technique makes a certain amount of sense, especially if the DAO is marked with the ‘transaction required” attribute. This forces all clients that use the DAOs to handle transactions and is a great safeguard since DAOs often utilize resources that require transactions such as the database. However, for in-house applications where the service and DAO layers are often developed by the same team, these safeguards are not always needed. In fact, it is possible to develop DAOs using plain CDI managed beans and inject them into EJBs at the service tier. To see what the code looks like, let’s check out the bid manager stateless session bean in listing 3.

Listing 3 BidService stateless session bean code

@Stateless #A
public class DefaultBidService implements BidService {
	@Inject #B
	private BidDao bidDao;
	...
	public void addBid(Bid bid) {
		bidDao.addBid(bid);
	}
	...
	}
	@Local
	public interface BidService {
	...
	public void addBid(Bid bid);
	...
	}

#A Marks POJO as stateless session bean

#B Injects non-EJB DAO

#C Marks interface as local

The bid DAO injected into the EJB is a CDI managed bean with an interface. The DAO relies on the transaction and thread-safety context of the EJB and does not need to have any services other than basic dependency injection offered by CDI. Any other services such as security and asynchronous processing are also likely best applied at the service tier rather than the persistence tier. Listing 4 shows the code for the DAO.

Listing 4 BidDao CDI managed bean

public class DefaultBidDao implements BidDao {
	@PersistenceContext #A
	private EntityManager entityManager;
	...
	public void addBid(Bid bid) {
		entityManager.persist(bid);
	}
	...
	}
	public interface BidDao {
	...
	public void addBid(Bid bid);
	...
	}

#A Injects the JPA 2 entity manager

As such, the DAO is very simple. In fact, some of you might be surprised that neither the DAO class nor the interface has any annotations on it at all. This is really quite normal in the CDI world since CDI-managed beans truly are bare POJOs. When CDI sees the @Inject annotation in the bid service EJB, it simply looks for any object that implements the BidDao interface and injects it. It is important to note that the bid DAO is nameless—it does not have an @Named annotation. This is because the DAO really does not need to be referenced by name anywhere. The DAO also does not have a defined scope. When this happens, CDI assumes that the bean belongs in the default scope. By default, CDI creates a brand new instance of the bean and injects it into the dependent component—basically the same behavior as a “new” operator at the injection point. Notice also that the bid DAO itself can request injection as well. In the example, CDI injects a JPA 2 entity manager into the DAO that is used to save the bid entity into the database.

The CDI features you saw in this article are truly the tip of the iceberg. CDI has a vast array of other features like stereotypes, events, interceptors, and decorators.

Summary

We showed you what to expect from the new version of the Java enterprise platform, specifically, how CDI and EJB 3 work together seamlessly across application tiers.

also read:

• EJB Interview Questions
• How to secure EJB applications?
• Using CDI with EJB 3.0
• J2EE Books

• EJB Interview Questions
• How to secure EJB applications?
• Using CDI with EJB 3.0
• J2EE Books

Download Source Code

• Transactions in EJB 3.0 Sample Code

Container managed transactions in EJB 3.0

It is possible for applications to provide an indication that the transactions can be managed by the Container. Such transactions which are not managed through the application’s code but through the container are called Container managed transactions. It is the responsibility of the application developer to specify the transaction demarcation through transactional attributes. This information can be specified either through Annotations or through the configuration file. Note that specifying the transactional metadata through annotations is not available until the version 3.

Transactional Attributes

Container managed transactions are supported through various transactional attributes. The available transactional attributes are as follows

• Required
• Requires New
• Supports
• Not Supported
• Mandatory
• Never

Required

This is the default attribute if the transactional attribute is not specified. This indicates to the container that the annotated business method has to execute within a transaction. More specifically, when there is an active transaction, and if a business method is called from within the active transaction, then the method executes as if it is part of the transaction. This means that the success or the failure of the transaction will be propagated to this transaction. When the caller is not part of a transaction, then a new transaction is started. Consider the following code snippet,

package net.javabeat.articles.ejb.txnmgmt.container.required;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;

@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
public class EmployeeDetailBean implements EmployeeDetailLocal {

    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void createEmployeeDetail() {

    }
}

In the above enterprise bean definition, we have annotated the method createEmployeeDetail() with the ‘Required’ annotation. This business method will be called from the EmployeeBean which is defined below.

package net.javabeat.articles.ejb.txnmgmt.container.required;

import javax.ejb.EJB;
import javax.ejb.Stateless;

@Stateless
public class EmployeeBean implements EmployeeLocal {

    @EJB
    private EmployeeDetailLocal employeeDetailBean;

    public void createEmployee() {
        // Create employee here
        employeeDetailBean.createEmployeeDetail();
    }
}

As we can see in the createEmployee() method, the employee object is expected to be created first followed by the creation of employee detail object. Now if there is exception before the return of the business method ‘createEmployee()’ then the employee detail object won’t be created.

Requires New

The transactional attribute ‘Requires New’ will also start a new transaction irrespective of the fact that the caller is in active transaction or not. This attribute can be applied to business methods where the result of the calling transaction is not dependent on the business method that is annotated with ‘Requires New’.

package net.javabeat.articles.ejb.txnmgmt.container.requiresnew;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;

@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
public class DepartmentBean implements DepartmentBeanRemote {

    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public void createDepartment() {
    }
}

Considering the above example, we have a business method that creates a department object and the method is annotated with the transactional attribute ‘Requires New’. Now consider the below code,

package net.javabeat.articles.ejb.txnmgmt.container.requiresnew;

import javax.ejb.EJB;
import javax.ejb.Stateless;

@Stateless
public class EmployeeBean implements EmployeeBeanRemote {

    @EJB
    private DepartmentBeanRemote departmentBean;

    public void createEmployee() {
        // Create employee object here
        departmentBean.createDepartment();
       // Assign the newly created department object to the employee object
    }
}

Here after creating the employee object, we call the enterprise bean for creating a department. Let us assume that we a creating a new employee object and during the course of creation, we also want to create a new department object and assign it to the employee object. Now imagine a transactional failure before the return of the method createEmployee(), in which case, the creation of the department won’t be rolled back because the department creation process is in a separate transaction. This also means that when we create a different employee object we can assign this employee object to the already created department object.

Supports

The transactional attribute ‘Supports’ defines that the transactional mode has to be propagated from the caller to the business method that is annotated with ‘Supports’. This means that if the caller is in an active transaction, then the business method will also execute as part of the active transaction. This means that a failure in the business method will revert the caller’s transaction also. If the caller is not part of the transactional context, then the business method will also execute in a non-transactional context.

Not Supported

This transactional attribute can be used for scenarios where a part of the business operation shouldn’t be executed in a transactional context at all. If the caller is part of the transaction, then the caller’s transaction is suspended and resumed once the execution of the business method that is annotated with ‘Not Supports’ is completed. If the caller is not part of any transaction, then also the business method will execute outside the transactional context.

package net.javabeat.articles.ejb.txnmgmt.container.requiresnew.notsupported;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;

@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
public class MailSenderBean implements MailSenderLocal {

    @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
    public void sendMail() {
    }

}

In the above example, we have modeled a simple sessionbean that sends a mail. Let us assume that this bean will be used as part of some user registration process. That is, once the user is registered, the application will try to send a mail by calling this enterprise bean. Because the operation of sending a mail to the customer can’t be part of a transaction, the method is annotated with ‘Not Supported’. Have a look at the caller’s code.

package net.javabeat.articles.ejb.txnmgmt.container.requiresnew.notsupported;

import javax.ejb.EJB;
import javax.ejb.Stateless;

@Stateless
public class UserRegistrationBean implements UserRegistrationLocal {

    @EJB
    private MailSenderLocal mailSenderBean;

    public void registerUser() {

        // Do user registration here
        mailSenderBean.sendMail();
    }
}

Mandatory

The transactional attribute ‘Mandatory’ can be used when we wanted to make sure that some business method has to be executed as part of a transaction. If the caller’s code is not part of the transaction, then an exception will be thrown. Have a look at the below code.

package net.javabeat.articles.ejb.txnmgmt.container.mandatory;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;

@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
public class MoneyTransferBean implements MoneyTransferLocal {

    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public void transferMoney() {

        deductMoneyFromSource();
        addMoneyToDestination();
    }

    @TransactionAttribute(TransactionAttributeType.MANDATORY)
    public void deductMoneyFromSource() {
    }

    @TransactionAttribute(TransactionAttributeType.MANDATORY)
    public void addMoneyToDestination() {
    }
}

We have defined three business methods ‘transferMoney’, ‘deductMoneyFromSource’ and ‘addMoneyToDestination’. If we assume that the business method ‘deductMoneyFromSource’ and ‘addMoneyToDestination’ should be part of some transactional method ‘transferMoney’, then these methods have to be annotated with ‘Mandatory’ annotation. This ensures that the business methods ‘deductMoneyFromSource’ and ‘addMoneyToDestination’ cannot be and shouldn’t be executed from a non-transactional environmental context.

Never

This is a rarely used transactional attribute as an exception will be thrown if a caller, as part of an active transaction, executes a business method that is annotated with ‘Never’.

package net.javabeat.articles.ejb.txnmgmt.container.never;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;

@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
public class DataLoaderBean implements DataLoaderLocal {

    @TransactionAttribute(TransactionAttributeType.NEVER)
    public void loadDataFromXml(String xmlFilename) {
    }

    @TransactionAttribute(TransactionAttributeType.NEVER)
    public void loadDataFromFlatFile(String filename) {
    }

}

In the above example, we have business methods for loading data from a non-transactional data resource such as the file system. Hence we have given the transactional attribute as ‘Never’.

Bean Managed transactions in EJB 3.0

Now that we have seen the advantages and the usage of CMT, let’s see where and how to use Bean Managed Transactions. Even though it is quite uncommon, still there are scenarios where customizations with respect to transaction handling might be required at the application level. The level of customization include when to begin a transaction in a business method, when to commit a transaction by defining a successful scenario and when to rollback a transaction for a failure scenario. For example consider the sample code,

package net.javabeat.articles.ejb.txnmgmt.bean;

import javax.annotation.Resource;
import javax.ejb.Stateless;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;
import javax.transaction.UserTransaction;

@TransactionManagement(value=TransactionManagementType.BEAN)
@Stateless
public class BillPaymentBeanBean implements BillPaymentBeanLocal {

    @Resource
    private UserTransaction userTransaction;

    public void payBill() throws Exception{

        try{
            userTransaction.begin();

            provideBillDetailsInfo();
            identifyCustomerAccount();
            makeBillPayment();

            userTransaction.commit();
        }catch (IncorrectBillDetailsException exception){
            userTransaction.rollback();
        }catch (InvalidCustomerAccountException exception){
            userTransaction.rollback();
        }catch (PaymentException exception){
            userTransaction.rollback();
        }
    }

    private void identifyCustomerAccount()
        throws InvalidCustomerAccountException {
    }

    private void makeBillPayment() throws PaymentException{
    }

    private void provideBillDetailsInfo()
        throws IncorrectBillDetailsException{
    }
}

The first obvious thing to be noted in BMT is that we have to use @TransactionManagement(BEAN) to instruct the container that we are using Bean managed transactions for this enterprise bean. The above example shows how to use BMT with the help of UserTransaction interface. UserTransaction provides a single entry point for managing bean managed transactions and to obtain a valid reference to this interface, the annotation @Resource can be used. This makes sure that the container populates the UserTransaction reference and makes it available. To signal the logical beginning of a transaction, the method begin() can be used. Similarly there are commit() and rollback() signaling that the transaction is successful or failure respectively. Note that in the above example case, whenever we encounter a exception scenario, we indicate that the transaction is a failure by calling the rollback() method. The code snippet for the related exception classes are given below.

package net.javabeat.articles.ejb.txnmgmt.bean;
public class IncorrectBillDetailsException extends Exception{
}

package net.javabeat.articles.ejb.txnmgmt.bean;

public class InvalidCustomerAccountException extends Exception {
}

package net.javabeat.articles.ejb.txnmgmt.bean;

public class PaymentException extends Exception{

}

Handling Exceptions in EJB 3.0

It is important to understand the effect of exceptions when dealing with transactional business methods. In the context of Enterprise beans, exceptions can be either classified as System Exception or Application Exception.

System Exception

The default behaviour of the EJB Container is to rollback the transaction whenever a System exception occurs. Any Exception that is a subclass of RuntimeException or RemoteException will be classified and treated as a System exception. This is the default exception handling when the transaction is managed by the container. When a system error is encountered, the calling client will always perceive that exception as a instance of EJBException or RemoteException. However in the case of Bean managed transactions, it is upto the application as how to handle the system exception, though it is considered as a bad programming practice to catch a system exception and not performing a rollback. For example, consider the following code snippet

@Resource
private UserTransaction transaction;
public void someBizMethod(){

	try{
		transaction.begin();
	}catch (NullPointerException npe){
		transaction.commit();
	}
}

In the above exception, even through NullPointerException is a system exception (because NullPointerException is an instance of RuntimeException), we are making a commit by calling the transaction’s commit() method.

Application Exception

Application exceptions are generally thrown when the attempt is made to execute a business method results in an error because during the course of the execution it is identified that some business logic went wrong. For example, while performing money transfer between two accounts it is mandatory that sufficient funds have to be present in the source account. An application error can be thrown during the execution of this business method because of insufficient funds. By default when an application error is thrown, the container won’t rollback the transaction as opposed to System exceptions. Also the exception will be reached its client in its regular form, i.e unlike System exceptions, where the source of the exception will be wrapped as either EJBException or RemoteException.

There can be cases where we want to make the transaction rollback for an application exception. In the case of a Bean managed transaction, this scenario is straight-forward, as the application has the control over the UserTransaction. Rolling the transaction would be as simple to call the method rollback(). However, in the case of the Container managed transactions, the situation becomes quite tricky and the annotation @ApplicationException comes to the rescue. For example, let us consider that in the example of money transfer, if sufficient amount is not available in the source account, then we want to throw a customized exception called InsufficientFundsException and also to rollback the transaction.

@ApplicationException(rollback=true)
public class InsufficientFundsException extends Exception{
	public InsufficientFundsException(String message){
	}
}

In the above code snippet, we have created a customized exception along with the annotation Application Exception with the attribute rollback set to true. This ensures that for a business method, that declares this exception at the throws clause, when this exception is encountered during the execution of the business operation, the container will request for a transaction rollback.

Persistence Context and Entity Manager

Closely associated with EJB transactions are Entity Manager and Persistence Contexts. Entity Manager is an interface for managing entites whereas Persistence Context is an annotation that can be applied on Entity Manager instances. The annotation has name, persistence unit name and type. The persistence unit name, if specified has to match the unit name that is defined in the persistence.xml file. Persistence context can either be transaction scoped or extended scoped. If the persistence context operates in transaction scope, then it means that the entities that are associated with the persistence context have the life-time equal to that of the transaction. That is, when the transaction ends, any changes done to the entities wont get notified to the persistence context. However, in the case of the extended persistence context, the entities will be attached to the persistence context even after the completion of the transaction. The entities will be detached from the persistence context only when the method close() is called on the Entity Manager object.

Consider the following piece of code,

package net.javabeat.articles.ejb.transactions.application;

import java.util.List;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Stateless
public class ApplicationFacade implements ApplicationFacadeRemote {

    @PersistenceContext
    private EntityManager em;

    public void create(Application application) {
        em.persist(application);
    }

    public void edit(Application application) {
        em.merge(application);
    }

    public void remove(Application application) {
        em.remove(em.merge(application));
    }

    public Application find(Object id) {
        return em.find(Application.class, id);
    }

    public List findAll() {
        return em.createQuery("select object(o) from Application as o").getResultList();
    }
}

Note that the entity manager reference is injected by the container as it is annotated with @PersistenceContext annotation. If the persistent unit name is not specified as part of the annotation, then by default, the file name persistence.xml will be looked up for finding the persistence name. The contents of the persistence.xml is given below,

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
  <persistence-unit name="Application-ejbPU" transaction-type="JTA">
    <provider>oracle.toplink.essentials.PersistenceProvider</provider>
    <jta-data-source>new</jta-data-source>
    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <properties>
      <property name="toplink.ddl-generation" value="drop-and-create-tables"/>
    </properties>
  </persistence-unit>
</persistence>

Conclusion

This article started by exploring the various techniques of managing transactions in an EJB environment – namely the Container Managed transactions and Bean managed transactions. The various transactional attributes that are applicable for contained managed transactions are given a healthier discussion under the section ‘Transactional attributes’. Also for easier understanding, many sample code snippets were presented for illustration. Then the article went on with discussing the usage the Bean managed transactions. Because it is essential to understand the impact of exception handling with respect to transactions, the final section of the article explained the exception handling mechanisms for System Exceptions and Application Exceptions.

also read:

• EJB Interview Questions
• How to secure EJB applications?
• Using CDI with EJB 3.0
• J2EE Books

• JPA in NetBeans 6.1
• EJB 3.0 and WebServices
• Introduction to Java Persistence API(JPA)
• EJB 3.0 Timer Services – An Overview

What This Book Covers

In Chapter 1, What’s New in EJB 3.0, we discuss the new features in the EJB 3.0
specification, such as support for metadata annotations, default values for configuration,
simplified session and entity beans, and enhanced support for checked exceptions.

In Chapter 2, Converting an EJB 2.0 Entity to an EJB, we convert an example EJB 2.0
entity bean to an EJB 3.0 entity bean. We also generate the session bean façade for the
EJB 3.0 entity bean. XSLT transformation is used for converting the EJB 2.0 entity bean
to an EJB 3.0 entity bean.

In Chapter 3, EclipseLink JPA Persistence Provider, we discuss the JPA framework and
the EclipseLink persistence provider.

In Chapter 4, Building an EJB 3.0 Persistence Model with Oracle JDeveloper, we discuss
EJB 3.0 database persistence with JDeveloper 11g, WebLogic Server 11g, and Oracle
Database 10g. We create an EJB 3.0 entity bean from a database table, create a session
bean façade, and finally create a JSP test client. Using the test client, we create, retrieve,
and delete entity bean instances.

In Chapter 5, EJB 3.0 Persistence with Oracle Enterprise Pack for Eclipse, we discuss the
same example we covered in Chapter 4, but with the Oracle Enterprise Pack for Eclipse,
WebLogic Server, and the open source MySQL database, which has been acquired by
Oracle.

In Chapter 6, EJB 3.0 with ADF Faces UI, we discuss using an ADF Faces client for EJB
3.0 database persistence. We create an entity bean using data input from an ADF Faces
user interface (UI). Subsequently, we find an entity bean instance using data input from
an ADF Faces UI.

In Chapter 7, Creating EJB 3.0 Entity Relationships, we discuss EJB 3.0 entity
relationships using, as an example, three entity beans that have inter-relationships. We
also discuss the significance of a fetch strategy.

In Chapter 8, EJB 3.0 Database Persistence with Ajax in the UI, we discuss EJB 3.0
database persistence in combination with Ajax in the user interface (UI). We demonstrate
data validation and autocompletion with Ajax.

In Chapter 9, Using JSF with Entity Relationships, we discuss adding JSFs to EJB 3.0
database persistence to create and persist entity bean instances that have entity
relationships between them.

In Chapter 10, Creating an EJB 3.0 Web Service, we create a JAX-WS Web Service from
an EJB 3.0 entity bean, create a web service client, package and deploy the web service
to WebLogic Server, and test the Web Service using the WebLogic console.

Building an EJB 3.0 Persistence Model with Oracle JDeveloper

Oracle Fusion Middleware is a family name for a set of Java EE products that are
integrated for SOA and web application deployment. WebLogic Server (WLS) is the
Java EE container and Oracle JDeveloper the Java EE and SOA development IDE.
In this chapter, we will use JDeveloper to create an EJB 3.0 application, and then we
will deploy and test our application leveraging the embedded WebLogic Server that
comes with JDeveloper. This makes it very easy for us to develop, deploy, and test
our application.

WebLogic server 10.x provides some value-added features to facilitate EJB
3 development. WebLogic server 10.x supports automatic deployment of a
persistence unit based on the injected variable’s name. The @javax.persistence.
PersistenceContext and @javax.persistence.PersistenceUnit
annotation s are used to inject the persistence context in an EntityManager or
EntityManagerFactory variable . A persistence context is a set of entities that are
mapped to a database with a global JNDiname. If the name of the injected variable
is the same as the persistence unit, the unitName attribute of the
@PersistenceContext or @PersistenceUnit is not required to be specified. The
EJB container automatically deploys the persistence unit and sets its JNDiname to
be the same as the persistence unit name in persistence.xml. For example, if the
persistence unit name in the persistence.xml file is em, an EntityManager variable
may be injected with the persistence context as follows:

	@PeristenceContext

	private EntityManager em;

We did not need to specify the unitName attribute in the @PersistenceContext
because the variable name is the same as the persistence unit. Similarly, an
EntityManagerFactory variable may be injected with the persistence context as
follows, emf being also the persistence unit name:

	@PersistenceUnit

	private EntityManagerFactory emf;

Another value-added feature in WebLogic server 10.x is support for vendor-specific
subinterfaces of the EntityManager interface . For example, the BEA Kodo persistence
provider provides the KodoEntityManager subinterface , which may be injected with
the persistence context as follows:

	@PersistenceContext

	private KodoEntityManager em;

Setting the environment

Before getting started, we need to install Oracle JDeveloper 11g, which may be
downloaded from http://www.oracle.com/technology/products/jdev/index.
html. Download the Studio Edition, which is the complete version of JDevloper
with all the features. Oracle JDeveloper 11g is distributed as a GUiself-extractor
application. Click on the jdevstudio11110install application. The Oracle Installer
gets started. Click on Next in the Oracle Installer. Choose a middleware home
directory and click on Next.

Choose the Install Type as Complete, which includes the integrated WebLogic
Server, and click on Next.

Confirm the default Product Installation directories and click on Next.

The WebLogic Server installation directory is the wlserver_10.3 folder within
the middleware home directory. Choose a shortcut location and click on Next.
The Installation Summary lists the products that are installed, which include the
WebLogic Server and the WebLogic JDBC drivers. Click on Next to install Oracle
JDeveloper 11g and the integrated WebLogic Server 10.3.

We also need to install the Oracle database 10g/11g or the lightweight Oracle XE ,
which may be downloaded from http://www.oracle.com/technology/software/
products/database/index.html. When installing Oracle database, also install the
sample schemas.

Creating a datasource in JDeveloper

Next, we create a JDBC datasource in JDeveloper. We shall use the datasource in the
EJB 3.0 entity bean for database persistence. First, we need to create a database table
in some sample schema, OE for example. Run the following SQL script in SQL *Plus:

	CREATE TABLE Catalog (id INTEGER PRIMARY KEY NOT NULL, journal

	VARCHAR(100), publisher VARCHAR(100), edition VARCHAR(100), title

	VARCHAR(100), author VARCHAR(100));

A database table gets created in the OE sample schema.

Next, we need to create a JDBC connection in JDeveloper with Oracle database. Open
the Database Navigator or select the Database Navigator tab if already open. Rightclick
on the IDE Connections node and select New Connection.

In the Create Database Connection window, specify a Connection Name, select
Connection Type as Oracle (JDBC), specify Username as OE, which is the schema
in which the Catalog table is created, and specify the password for the OE schema.
Select Driver as thin, Host Name as localhost, SID as ORCL, and JDBC Port as
1521. Click on the Test Connection button to test the connection. If the connection
gets established, click on OK.

The OracleDBConnection gets added to the Database Navigator view. The
CATALOG table that we created is listed in the Tables.