The salary cap is an example of a limited resource that a service must
not over commit. Another example might be seats on an airline flight
although most airlines have yet to implement an accurate solution :>).
Let's call this the accurate reservation problem.
There are many ways to implement this with EJB.
A basic implementation would use a database record to store the current
resource value and access it with full database isolation. The database
would serialize all resource requests. If desired this record could be
wrapped with a session bean (in effect this appears to be a 'singleton'
session).
A more sophisticated implementation that improves concurrency would be a
resource reservation service . Early in the transaction the user task
would reserve its resources and then late in the transaction confirm
them. The reservation method would use the RequiresNew transaction mode
and the confirm method would use the Required mode. This implementation
improves concurrency over the basic implementation; it insures the
resource is not over committed because the reservations are serialized;
it insures the that only fully completed tasks result in a confirmed
reservation; however, the application will need to recover the
occasional unconfirmed reservation. A simple way to do this is to time
out expired reservations in the reservation method and reject
confirmations that don't match an outstanding reservation.
The point I'm making is that EJB provides many ways of implementing a
practical solution for the accurate reservation problem. Developers
should not attempt to use Java synchronization to solve this problem.
Use EJB and transaction synchronization instead.
-- Mark
James Cook wrote:
>
> Sometimes when working with an object, a developer will want to lock a
> collection of objects. For example, assume the following conditions:
>
> 1. An NBA team has to live under a salary cap.
> 2. Team management may be modifying two players salaries simultaneously.
> 3. They submit their changes at the same time.
>
> In reality, the business rule that must be checked at submittal relates to the
> player's salary increase busting the salary cap. This is prevented by checking
> the teams collective salaries and not allowing the post to succeed if the
> business rule is violated.
>
> Without a locking mechanism in place (or some other design consideration), it
> will always be possible for the above scenario to fail. If both submit requests
> ask for the total salary cap before either one writes to the database, than both
> commits have the possibility of succeeding. This can happen even if the business
> rule is violated.
>
> An elegant solution is to create a team lock object that must be checked out
> prior to obtaining the salary total for a team, and is released after the
> database write. By allowing only one process a lock at a time solves the
> problem. This can easily be done using Java's threading capabilities and the
> wait/notify mechanism.
>
> Now for the question...
>
> How can this mechanism be implemented in EJB?
>
> It seems like I would need a Singleton Session Bean, although this goes against
> the concept of a session bean as every client would have to access the same
> object to guarantee proper locking.
>
> Since there is a single lock object, I tended to look at an Entity Bean. Would
> it be good design (as related to the salary cap example) to make a Finder method
> that goes into a wait state if the entity bean is currently locked by another
> process? This seems to be where I am leaning.
>
> Is it possible to take advantage of EJB transactions to prevent the salary cap
> business rule violation? I don't think this is a transaction problem as much as
> a locking issue...
>
> Any thought or comments?
> jim
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
