On Mon, 29 Dec 2003 16:22:29 -0600, Bob Lee <[EMAIL PROTECTED]> wrote:
>We have a global configuration object that's expensive to create. In the >past, we had only one instance per JVM and everything performed >acceptably. The object contains a list of servers. Servers can be >removed from the list at runtime if they go down, so the object needs >some synchronization. > >A coworker on another team read the "no statics, no synchronization" >rule in the specification and has removed the synchronization and now >creates a copy of the object per EJB. This kills performance. > >The coworker is reluctant to revert the code until they are convinced >that doing so would not violate the spec. I've explained that this is >meant for bean providers, more specifically business objects that are >expected to be transactional and unique across the entire application, >not applications like this where it's acceptable to have multiple >copies, but you want to limit the number for the sake of performance. > >Can someone from Sun please chime in and provide the needed support to >convince this person? I'm not from Sun, but I'll be glad to chime in. If the config object you're talking about is referenced by a static variable in one of your EJB implementation classes, then it probably is a good idea to find another solution. Not only would that violate the spec, but it could cause any number of unforseeable problems. You never know what an EJB container might choose to do under the hood; it might even load your EJB implementation class multiple times in multiple classloaders, which would result in multiple instances of your "static" config object. OTOH, if you're using a Singleton implementation of this config object that lives completely outside of any EJB class (i.e. the static reference and the usual synchronization are inside the config class itself) then, as I read it, that violates neither the letter nor the spirit of the spec. (I base this conclusion on the language that says "it is recommended that all static fields IN THE ENTERPRISE BEAN CLASS be declared as final.") You would still have to be careful not to call the synchronized getSingletonInstance() method in such a way that might cause a deadlock, but that shouldn't be too difficult. If this argument doesn't satisfy your coworker, you might ask him/her if he/she feels it's OK to call methods on a Hashtable or Vector from within an EJB. After all, many of the methods of those classes are synchronized. -- Check out QueryForm, a free, open source, Java/Swing-based front end for relational databases. http://qform.sourceforge.net =========================================================================== 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".
