barcode font vb.net Building business logic with session beans in Java

Printing Data Matrix ECC200 in Java Building business logic with session beans

@Remote(BidManager.class) @Stateless public class BidManagerBean { ... }

The preceding code marks the BidManager interface as remote through the bean class itself. This way, if you change your mind later, all you d have to do is change the access type specification in the bean class without ever touching the interface. Next, we move on to discussing the EJB lifecycle in our example.

We introduced you to lifecycle callback methods, or callbacks, earlier in the chapter; now let s take a deeper look at how they are used with stateless session beans. As far as EJB lifecycles go, stateless session beans have a simple one, as depicted in figure 3.5. In effect, the container does the following:

Figure 3.5 The chicken or the egg the stateless session bean lifecycle has three states: does not exist, idle, or busy. As a result, there are only two lifecycle callbacks corresponding to bean creation and destruction.

1 2 3 4

Creates bean instances using the default constructor as needed. Injects resources such as database connections. Puts instances in a managed pool. Pulls an idle bean out of the pool when an invocation request is received from the client (the container may have to increase the pool size at this point). Executes the requested business method invoked through the business interface by the client. When the business method finishes executing, pushes the bean back into the method-ready pool. As needed, retires (a.k.a. destroys) beans from the pool.

An important point to note from the stateless session bean lifecycle is that since beans are allocated from and returned to the pool on a per-invocation basis, stateless session beans are extremely performance friendly and a relatively small number of bean instances can handle a large number of virtually concurrent clients. As you know, there are two types of stateless session bean lifecycle callback methods: (1) callbacks that are invoked when the PostConstruct event occurs immediately after a bean instance is created and set up, and all the resources are injected; and (2) callbacks that are invoked when the PreDestroy event occurs, right before the bean instance is retired and removed from the pool. Note that you can have multiple PostConstruct and PreDestroy callbacks for a given bean (although this is seldom used) in a class or in a separate interceptor class (discussed in chapter 5). In listing 3.1, the lifecycle callback methods embedded in the bean are initialize and cleanup. Callbacks must follow the pattern of void <METHOD>(). Unlike business methods, callbacks cannot throw checked exceptions (any exception that doesn t have java.lang.RuntimeException as a parent). Typically, these callbacks are used for allocating and releasing injected resources that are used by the business methods, which is exactly what we do in our example of BidManagerBean in listing 3.1. In listing 3.1 we open and close connections to the database using an injected JDBC data source. Recall that the addBid method in listing 3.1 inserted the new bid submitted by the user. The method created a java.sql.Statement from an open JDBC connection and used the statement to insert a record into the BIDS table. The JDBC connection object used to create the statement is a classic heavy-duty resource. It is

expensive to open and should be shared across calls whenever possible. It can hold a number of native resources, so it is important to close the JDBC connection when it is no longer needed. We accomplish both these goals using callbacks as well as resource injection. In listing 3.1, the JDBC data source from which the connection is created is injected using the @Resource annotation. We explore injecting resources using the @Resource annotation in chapter 5; for now, this is all that you need to know. Let s take a closer look at how we used the callbacks in listing 3.1. PostConstruct callback The setDataSource method saves the injected data source in an instance variable. After injecting all resources, the container checks whether there are any designated PostConstruct methods that need to be invoked before the bean instance is put into the pool. In our case, we mark the initialize method in listing 3.1 with the @PostConstruct annotation:

@PostConstruct public void initialize() { ... connection = dataSource.getConnection(); ... }

In the initialize method, we create a java.sql.Connection from the injected data source and save it into the connection instance variable used in addBid each time the client invokes the method. PreDestroy callback At some point the container decides that our bean should be removed from the pool and destroyed (perhaps at server shutdown). The PreDestroy callback gives us a chance to cleanly tear down bean resources before this is done. In the cleanup method marked with the @PreDestroy annotation in listing 3.1, we tear down the open database connection resource before the container retires our bean:

@PreDestroy public void cleanup() { ... connection.close(); connection = null; ... }

Since bean instances from the pool are assigned randomly for each method invocation, trying to store client-specific state across method invocations is useless