Discussions

EJB design: Global variables in EJB3

  1. Global variables in EJB3 (6 messages)

    Our server has to cache various kinds of data with quite complex structure. We can't simply read the data from database for each request because performance would be unacceptable. We need to store the data somewhere in memory to have fast access to it. We could use global variables (static class fields) in J2SE Java but that seems to be forbidden for JEE code. For now we just ignored this restriction and our server code running in JBoss successfuly uses static class fields to store global data. We never had problems during development but we never run the code in serious production environment. Can static class fields really cause trouble and why ? Is there any other *portable* means to keep global variables ? We could use JBoss cache but we don't want to bind ourselves to JBoss.

    Threaded Messages (6)

  2. Re: Global variables in EJB3[ Go to top ]

    JBoss Cache runs in any JEE application server.
  3. Re: Global variables in EJB3[ Go to top ]

    The underlying technology should handle transparently all the caching. I don't know well EJB3 but with Hibernate, you can completly configure that cache and specify what kind of policy you want for each type of object. And when correctly configured, accessing twice the same object doesn't necessarily reload it from the database. IMO when you need to implement your own caching in a J2EE server, it means that something is wrong in your software stack/configuration. Anytime soon you might hit another cache/scaling issue.
  4. Re: Global variables in EJB3[ Go to top ]

    One of the possibility could be to use a ThreadLocal variable.
  5. Not cool[ Go to top ]

    I'm using ThreadLocal but it is not a cool API. Are there any problems for using that?
  6. Re: Global variables in EJB3[ Go to top ]

    I would have gone for multiple read-only Entity Beans and set the variables and their values which need to be cached. Ensure, only one instance of the Bean for your global variables exists in the memory.
  7. clustered versus not[ Go to top ]

    Static fields are only a problem on redeployment or when clustering. If not hot redeploying or clustering, static is OK. If hot redeploying, then static must be on a class in the classpath (not part of the hot redeploy) and the type of the object stored in the static (and everything it references) must also be in the classpath. If clustering, use Tangosol Coherence as a data grid. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid