Shared Memory in EJB Container

[treespace]

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.

[treespace]

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.

[epbernard]

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

[martinganserer]

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

[epbernard]

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

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

[epbernard]

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

[treespace]

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.

[epbernard]

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

[treespace]

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.