EJB Stateless Initialization Pattern

Question

I have an EJB Stateless Session Bean. I have these requirements:

1. This Stateless EJB should be initialized at startup
2. The initialization code should make a transactional access to a database

The problem is:

1. @Startup is only available for @Singleton EJBs
2. @PostConstruct annotation (at least on Websphere) doesn't have a transactional context at this point so the initialization code explode here!

Possible solutions?

1. Use a Java EE Timer but it seems to be designed for periodic execution. I want just only one execution at time zero.
2. Use a @Singleton + @Startup EJB just for initialization purposes and inject this singleton EJB to the dependant Stateless EJBs.

Question:

1. Can any one explain how it is supposed a Stateless EJB to be initialized? or it has no sense? (I mean, stateless EJB are supposed to not to have initialization state?)
2. Is there any pattern out there that says use of secondary EJB @Singleton with @Startup is a good idea?

Scowl

I am surprised that Websphere does not have a TX context for @PostConstruct because that is mandated by the EJB 3.1 specification. What version of Websphere are you using? – Dashing

Transactional context is not mandated by spec. Check out this: docs.oracle.com/javaee/6/tutorial/doc/gkedm.html and blogs.oracle.com/arungupta/entry/what_s_new_in_ejb – Dovekie

Sorry I mis-read your post I thought you were talking about Websphere and @Singletons but after re-reading it I can see you are using 2) to refer to your original Stateless case. – Dashing

Answer 1

Finally i opted for:

• EJB @Stateless -- having a reference to --> EJB @Singleton (with @Startup)

That way, i can initialize the (shared and readonly) state or context necessary to serve requests.

Scowl

Answer 2

Initializing a stateless EJB has no sense since this is the job of the Java EE container. Moreover, Java EE 6 provides the IOC pattern natively. IOC basically means hiding injected resources initialization process.

Your 2. solution is correct, as you need a transactional access.

Then you need to consider both cases/states :

a. singleton started up correcty

b. singleton failed at startup

In other words, are you sure that your (1.) statement is correct or you may interpret it with a lazy-init pattern ?

As the @startup occurs when application startup, maybe a state on the singleton with a lazy init activation is also matching to your needs?

Barring

Answer 3

The initialization code should make a transactional access to a database.

It is not clear to me for what the database access is, but in case you need fetch some data and store it as attributes of your stateless seasion bean, take in mind the following:

• this information will be replicated in every stateless instance.

• you will execute a database query every time a new bean instance is created.

• at some point, it could be hard to be sure that all your beans instances have the same state.

I don't know the name of the pattern, but store the information in a Singleton session bean and inject it inside a stateless its a good solution. Even the Singleton bean can manage simultaneos requests, therefore, it won't become a bottleneck. It also allows you to manage possible information changes in a more consistent way.

Endgame

>you will execute a database query every time a new bean instance is created. - in this context; JBoss in their infinite wisdom has decided that it no longer pools stateless session beans at all. So for every call to a stateless bean in the latest versions of JBoss a new bean will be constructed and thus said query will be repeated. You can set it to start pooling again, but via a jboss specific setting. – Acetanilide