Wednesday, August 20, 2003 06:35 PM
The thing about these rules is that they are not enforced by the EJB container. You can break these rules as long as you know what you are doing.
Threads: The reason you shouldn't create threads is because EJBs abstract this for you. EJBs handle concurrency so why would you want to create threads? There is rarely a good reason to do so in an EJB application. Also, app servers have thread pools that allow you to configure and tune your application for performance. So using threads on top of this framework would defeat the purpose of an app server. But if you have a good reason for managing your own thread, it will still work.
Synchronized: There are cases where you need to synchronize methods inside an EJB-based app. For example, you are sharing a vector across all classes inside the ejb container. Here again, you need to know the consequences of this. EJB containers may use multiple classloaders for an application. The synchronize method will not synchronize a method for a same object that exists within 2 classloaders. This is also a problem for a clustered deployment.
As far as using a big hashtable, your current solution is fine. Just note the points I made in the previous paragraph.