>Question :
>Using Synchronized in Fire method will that stop anyone altering the
>criteriaStatus ? If not, what is rememdy? Should I create new fire
>signature of :
>        public synchronized void fire(RequestToValidate aRequest)  ?
>
>Is it possible for criteriaStatus to be altered between Setup, Execute
>& CleanUp methods?

This really isn't an EJB question, so you might try another list.  But
I'll try and take a shot at it here.

The rule with synchronized blocks is very limited: Two threads cannot
call synchronized methods on the same object at the same time.  Futhermore
any code that accesses a shared variable MUST access that variable
within a synchronized block, or it risks getting cached stale data instead.

In the code you showed, two threads cannot call the fire method on
the same object at the same time.  That's the only assurance you'll
get.  So the questions you have to ask yourself are:
+ Is there any other code that has access to your criteriaStatus object.

The answer to that question in your case is a most definite yes.
+ First your criteriaStatus variable is protected, which means methods in
your subclasses, which may or may not use proper thread synchronization,
will be able to access to read or change that variable.
+ Second, you're passing a reference to criteriaStatus to
aRequest.setTestResult().  In the code you showed me, there's no guarantee
that aRequest won't in turn make that reference available to other threads,
violating thread saftey.

So to summarize, here are the answer to your two key questions:
+ "Is it possible for two threads to call the fire method on the same
  object at the same time?"  The answer is no, the second thread calling
  the fire method will have to wait for the first thread to finish.
+ "Is it possible for criteriaStatus to be altered between Setup,
  Execute & CleanUp methods?"  The answer is yes, it is possible,
  because code outside the synchronized fire() method has access to
  the criteriaStatus variable.

How do you fix this problem?  The short approach is to make sure
code outside of the fire method doesn't have access to the criteriaStatus
variable.  If that solution is too restrictive, then you're going to need
get a good book on threads, as the complexity of the solution goes up
considerably.  You should get that book anyway, because there are
other problems that plague multithreaded systems, such as deadlocks,
which you'll need to understand and avoid.  Amazon.com has several good
books on Java Threads available.  I use the OReilly book on threads
and like it quite a bit.  If time is of the essence, the other option
is to hire a consultant with experience in multithreaded java to help you.
<shameless personal ad> Pick me, pick me </shameless personal ad>.

Doug

===========================================================================
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".

Reply via email to