8 Replies Latest reply on Apr 4, 2006 10:53 AM by treespace

    Shared Memory in EJB Container

    treespace Novice

      I have a service interface created with EJBs. I have a web application that uses those services but it's optional. What is the business tier equivalent of the servlet session context? JNDI?

      I am building up a data structure from the database so it has no direct persistence mapping. I want to keep it in memory where all stateless session beans have access to it.

        • 1. Re: Shared Memory in EJB Container
          treespace Novice

          It appears there is no such beast. You have to use the session context of a web application to host distributed applications. There is no shared context in Java EE that would allow a Swing front end to share code with a Web front end or a Web Services interface or an MDB driven interface.

          The various EJB technologies provide 98% of shared services but where does the state of a shared app go? That rather glaring need was identified early on, hence the ServletContext. Where's the web-free counterpart?

          The answer, my friend, is blowin' in the wind. It's called a JBoss singleton service. That's a place to keep the state of the application that's akin to using servlet context.

          I am going to use the servlet context for now but it seems strange that a web-less counterpart to that is not a standard part of JEEV. It means you have to persist application state for non-web front ends.

          • 2. Re: Shared Memory in EJB Container
            Emmanuel Bernard Master

            if you want a per user state, use a Stateful Session Bean
            if you want a per app state, you can probably use a Stateless Session keeping the state

            • 3. Re: Shared Memory in EJB Container
              Martin Ganserer Novice

              Hi,

              @epbernanrd:
              Please give us an example, as I don't belive that this will work!
              How should a stateless session keep the sate?

              Regards

              • 4. Re: Shared Memory in EJB Container
                Emmanuel Bernard Master

                @Stateless
                public class SomeStuffImpl impelments SomeStuff {
                private Map<String, Country> countriesSharedByEverybody;

                public Country getcountry(String name) {
                if (countriesSharedByEverybody == null) initialize();
                return countriesSharedByEverybody.get(name);
                }
                }

                • 5. Re: Shared Memory in EJB Container
                  Emmanuel Bernard Master

                  it does not keep the conversation state, this is what Stateless Session Bean means

                  • 6. Re: Shared Memory in EJB Container
                    treespace Novice

                    I was aware that state in a SLSBs was fine provided it was not conversational state between the client and the server. I dissmissed that option because the SLSBs are pooled and in my case clustered. Does an EJB container maintain coherence in SLSBs? If so that reall is a viable option.

                    • 7. Re: Shared Memory in EJB Container
                      Emmanuel Bernard Master

                      I don't know what you mean by coherence, but I would say no

                      • 8. Re: Shared Memory in EJB Container
                        treespace Novice

                        Coherence is short for "ensuring consistency across all of the constituent parts". SLSBs have to behaive exactly the same regardless of which instance you get or where that instance lives.

                        This is from the trailblazer on JMX which is why I think the Service bean is the way to go:

                        Different from EJB services, which are provided by a pool of managed objects, a JMX MBean service is provided by a singleton object in the server JVM. This service object is stateful and has an application-wide scope.


                        I read this as saying EJB services (stateless "session" beans) do not behave as singletons internally. I think that makes sense because there's nothing in the SLSB contract that says an SLSB's internal state is kept in sync.