@Singleton @Startup @PostConstruct method guaranteed to return before EJBs made available for client calls?

Question

In the context of a Java EE 6 application run on WebSphere 8.0, I need to execute a number of startup tasks before any business method can be executed. Using a @Startup, @Singleton bean for this purpose seems like a promising solution. However, it is not entirely clear to me how exactly the application lifecycle would look like. The EJB 3.1 spec states the following:

By default, the container is responsible for deciding when to initialize a Singleton bean instance. However, the bean developer can optionally configure the Singleton for eager initialization. If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any client requests are delivered to any enterprise bean components in the application.

1. In the last sentence, what exactly constitutes initialization? Will the container wait for the @PostConstruct method of the @Startup bean to return before making enterprise beans available to client requests?

2. Speaking of client requests, do scheduled executions of an EJB method with the @Scheduled annotation count as one in this context?

I need to guarantee that some code is executed on application startup before any of the business methods in any of the application's various EJBs can be run, be it through client calls or scheduled executions. Does running the startup code inside the @PostConstruct method of a @Singleton, @Startup bean provide such a guarantee? If not, is there any other way to guarantee this behavior?

Quintessence

Well, it would certainly be bad design for an application server to serve beans that are still in the middle of running their @PostConstruct methods. – Subdominant

@Subdominant There is a difference between serving beans in the middle of their @PostConstruct methods and preventing calls to all beans while any @Startup bean is in its @PostConstruct method, which is the behavior required by the spec. – Spearhead

@BrettKail Indeed there is. The latter guaranteeing that the former can't happen. However since his quote didn't explicitly mention @PostConstruct, I believe he was wondering whether @PostConstruct is part of initialization or not. – Subdominant

@Subdominant The section in the spec that discusses singleton initialization specifically discusses @PostConstruct methods. – Spearhead

@BrettKail But Lord Zuthulu (if that is his real name) didn't quote that part. I'm not confused here, I didn't post this question. – Subdominant

@Subdominant I probably could have worded the question better. Sorry if I caused any confusion. – Quintessence

Answer 1

1. Yes, the container waits for the @PostConstruct method of all @Startup beans in the module ("EJB application") to return before allowing any client requests.
2. Yes, this is the case in WebSphere Application Server as implied by the Developing singleton session beans topic in the Knowledge Center, which says "A PostConstruct method in a singleton bean can create an EJB timer [...] However, to avoid a deadlock, the PostConstruct method must not wait for an EJB timer to run". In other words, timer callback invocations will wait for @PostConstruct methods to complete, so @PostConstruct methods must not wait for timer callback invocations to complete.

Spearhead

This is exactly what I was looking for. Thanks! – Quintessence

I posted a similar question here. Could you take a look? – Metalliferous