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.
> -----Original Message-----
> From: Carl Jones [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 07, 1999 10:58 AM
> To: [EMAIL PROTECTED]
> Subject: EJBs and Synchronisation
>
> Hi,
>
> I've just read Mike Mannion's article on "Concurrent Contracts"
> in JavaReport (May 1999). One section of the article talks about
> "Command Query Separation" or CQS, where methods are designed to either
> be commands or queries but never both.
>
> The example given is..
>
> 1 if (club.roomForMember())
> 2 club.newMember(m);
> 3 else
> 4 System.out.println("Membership Exceeded");
>
> The problem in a concurrent situation is that between lines 2 & 4, another
> client could call newMember() and grab the last place.
>
> The solution proposed is to use synchronized thus
>
> 1 synchronized(club)
> 2 {if (club.roomForMember())
> 3 club.newMember(m);
> 4 else
> 5 System.out.println("Membership Exceeded");
> 6 }
>
> However, in the EJB specification (March 21, 1998), it says (section
> 16.4),
> "An Enterprise Bean is not allowed to use thread synchronization
> primatives".
>
>
> So, if I have a SessionBean calling an EntityBean, does this mean that my
> SessionBean can't use the above solution?
>
> If this is the case, one solution is to combine the check and the update
> into one method on the EntityBean, but this goes against CQS and
> the greater principle of design by contract.
>
> Any comments or ideas greatly appreciated.
>
> Thanks.
>
> Carl Jones
> BT
>
> (All opinions are my own and they might be different to employers)
>
> ==========================================================================
> =
> 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".
