A Session Bean’s no-interface view is a variation of the Local view that exposes the public methods of the bean class without the use of a separate business interface.
A client does not directly instantiate (use the new operator on) the bean class to acquire a reference to the no-interface view.
Kate Jackson wrote:
I must have gotten the wrong end of the stick, but isn't the LINE 1 read the same scenario as here:
If one thread calls setValue() there is no guarantee that subsequent reads in other threads via getValue() will ever see that value
(taken from java-concurrency-bugs-5-inconsistent-synchronization)
This would mean that at least theoretically there's a chance that the getAllFoos() method will never return actual state of the foos.
Henry Wong wrote:Second, just because something is volatile doesn't mean that it won't get stale. If your definition of stale is that it always need to be up to date, then what happens with the case where you load the reference, but before you use it (or finish using it), it gets changed. If that is your definition of stale, then volatile won't help -- you will need to grab the synchronize lock, and hold that lock until you finish processing the data.
Joseph Cho wrote:Also, if I set the boolean variables to static... shouldn't both threads be accessing the memory address of the variable? this is Why I don't get why the changes are not being reflected..