Java Reference
In-Depth Information
}
theatreBox.buyTicket(seatId);
money = money - seatPrice;
logger.infov("Seat {0} booked.", seatId);
return "Seat booked.";
}
}
As you can see, the previous bean bears a
@PostConstruct
annotation to initialize a
session variable (money) that will be used to check whether the customer has enough
money to buy the ticket. When using EJBs, we don't use
constructors
and
de-
structors
to perform actions on an object to create or destroy. The reason is that the
point object might not have injected all objects it depends on. The method annotated with
@PostConstruct
is executed when object creation is already finished, that is, all ob-
jects are injected to it. There is a second annotation related to the EJB life cycle,
@PreDestroy
, which is executed before the object is destroyed.
Besides this, the ultimate purpose of our SFSB is to invoke the
buyTicket
method of
our singleton after having performed some business checks.
If the business checks do not pass, the application will issue some exceptions. This is the
case, for example, if the seat has already been booked or if the customer hasn't got enough
money to buy the ticket. In order to keep our conversation going, it's important that our
exception will be an extension of the generic
Exception
class. Refer to the following
code for more information:
public class SeatBookedException extends Exception {
// some code
}
If we use a runtime exception (for example,
EJBException
), the bean instance will be
discarded, and the communication between the remote client and server will be dropped.
So, always take care to choose the appropriate type of exception when dealing with
EJBs—choose to throw a runtime exception if you are dealing with an unrecoverable
scenario (the connection with the enterprise information system is dropped). This kind of
exception is called a System Exception. On the other hand, consider throwing a checked
exception (or simply not throwing exceptions at all), if you are dealing with a business
