> <BOB>Actually, you're not supposed to use synchronization primitives to > synchronize the execution of multiple instances, as the bean may be > deployed in multiple VM's. This is not the case in the example below. > Actually, there will never even be contention for the lock below. The > same goes for statics.</BOB> > > Kindly Elaborate
Singletons are a good example. If you are truly only supposed to have one instance for the entire application, simply synchronizing access to a static field will not work. You will have an instance for each classloader (potentially multiple instances per VM). In the same way, if you're supposed to synchronize access for some resource for the entire application or across multiple bean instances, synchronization primitives obviously won't work as the instances may be running in different VM's. If you only need to synchronize locally, as is the case in the original author's example, go ahead. Another reason not cited by the specification could also be to prevent long critical points and deadlocks, however the rules and best practices here aren't different from any other application, EJB or not. The EJB architecture tries to insulate us completely from worries about synchronization or threading, and it's successful to an extent, but the fact is that there are some things it can't or shouldn't hide, IMO. Thanks, Bob =========================================================================== 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".
