Chris' response sparked a thought for this.
The original problem as stated by Carl was:
> > The example given is..
> >
> > 1 if (club.roomForMember())
> > 2 club.newMember(m);
> > 3 else
> > 4 System.out.println("Membership Exceeded");
But what I am wondering is why not just do the following:
try {
club.newMember(m);
} catch (NewMembersNotAllowedException e) {
System.out.println("Membership Exceeded.");
}
Now you get the 'synchronization' that you are seeking, since newMember protects
the state of the club object. It will call roomForMember() prior to modifying
the state of the club. And as Chris pointed out the transaction semantics of EJB
will permit only one thread into the method.
An additional benefit is the code loses the if-else syntax. Although there is no
change in the number of lines because of the try-catch.
In code:
public class Club {
public void newMember(Member m) throws NewMembersNotAllowedException {
if (roomForMember()) {
// add the member
} else {
throw new NewMembersNotAllowedException();
}
}
} // class
Just a thought.
Evan Koffler
Chris Raber wrote:
> The example only sychronizes/isolates one object in
> a Java VM process. What if that object represents
> state from a database of some sort? Or what if we
> have many java VM processes spread over many
> machines representing that same object? Obviously
> Java synchronization alone doesn't cut it here.
>
> EJB uses transaction isolation to handle this scenerio.
>
> In the example, club.newMember(m) would perform
> a database transaction that add a new member, and keep
> track of room for members. Given transaction isolation,
> if two or more where calling newMember in overlapping
> transactions, transaction isolation would save the day.
>
> -Chris.
>
===========================================================================
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".
