Pattern to initialize an EJB that depends on another application EJB

Question

How should I initialize an EJB when it depends on another application that is located in another cluster that is still not started?

How should I do it?

• @PostConstruct: Maybe I can loop until the dependant EJB is available, but I'm afraid it would timeout or block the server loading process.
• @Schedule: Maybe scheduling the initialization process to avoid blocks on server and then service requests only if init is done, otherwise throw an error.

How do you think should I proceed? Would you recommend me some Pattern?

Answer 1

All the above suggestions are valid, I think. It's a matter of the circumstances around your problem, I think.

Depending on whether or not you can independently start A, you can use a third element like Gas suggested to guarantee that A does not come up (and fail or gets stuck) if B is not ready.

If on the other hand, A starts automatically and you cannot change that, then it depends on whether or not you can control when the initalization process happens. If you, schedule the initialization of the entire dependency chain and it should work, but if you don't know or can't control when B comes online and A will start no matter what, then there's no choice but to poll until B is up.

Personally, I've seen polling not be so bad as long as what you're waiting for is avaliable starts fast or recovers quickly in case of failure.

On another note, can you not control how the clusters start via their configuration? You could avoid the problem if you make the second application's cluster always start first.

Answer 2

Even if you manage to solve the initialization of the EJB, you will end up creating dependencies. Architecturally speaking, initialization dependency will undo the reason it was decided to split up App#1 (gateway) and App#2 (service host).

Alternative suggestion is to keep them independent, as they are currently, and instead rely on exception handling. If the service in App#2 is unreachable, you can choose to throw a custom exception like "Service not available, please try later" or, depending on the need, pool the requests to be executed when the service is available again.

This also protects you against the failure of App#2 after start up, for e.x. if it is down for maintenance or unresponsive due to some internal errors.