Java Reference
In-Depth Information
of proper encapsulation mixed with the pass-by-reference semantic (used in local and no-
interface views of EJBs) can lead to hard-to-find concurrency bugs. Using immutable ob-
jects as return values for singletons is a good strategy to solve these kind of problems.
Another strategy would be to return only copies of our objects or switching to the pass-by-
value semantic. The last strategy can be applied by switching to a remote business inter-
face in the singleton.
In the TheatreBox code, you have probably noticed a @AccessTimeout annotation
(with value 5 and unit TimeUnit.MINUTES ). When you execute a query against a
method with @Lock (WRITE) , and if some other thread is already accessing it, then
after 5 seconds of waiting, you will get a timeout exception. In order to change this beha-
vior (for example, by prolonging the allowed wait time), you can specify a
@javax.ejb.AccessTimout annotation at the method or class level.
Using bean-managed concurrency
The other possible option is to use a bean-managed concurrency strategy that can be pur-
sued by applying the @javax.ejb.ConcurrencyManagement annotation with an
argument of ConcurrencyManagementType.BEAN . This annotation will disable the
effect of the @Lock annotation we have used so far, putting the responsibility of ensuring
that the singleton cache does not get corrupted on the developer.
So, in order to ensure that our bookings are preserved, we will need to use a well-known
synchronized keyword on top of the buyTicket method, which is as follows:
public class TheatreBox {
. . . .
public synchronized void buyTicket(int seatId) {
final Seat seat = getSeat(seatId);
if (seat.isBooked()) {
throw new SeatBookedException("Seat " + seatId + "
already booked!");
Search WWH ::

Custom Search