Summary

It is sometimes useful for an EJB's interceptor to know if it was ultimately being called from the same EJB, or the same module, or the same application. It is also useful to know if an invocation which is blocked would permanently deadlock. To this end I propose that an EJB call stack mechanism is introduced.

Implementation

On each EJB method entry, a thread local is updated with an object which holds an identifier for the current EJB along with a link to the value that was previously in the thread local, if any. On asynchronous dispatch, the thread local value is copied, and cleared after task completion.

Deadlock detection

Once EJB locking is redesigned to use queues, it may be possible to introduce a deadlock detector using the call stack information. If a pair of EJBs (A and B) have concurrency control or another type of one-at-a-time restriction, and an invocation on A is blocked (directly or indirectly) due to an incomplete invocation on B, which in turn is blocked (directly or indirectly) due to A being incomplete, a deadlock exception can be raised to one or both of the participants, allowing the container to unwind and proceed. The detection could happen immediately upon entering the blocking queue, or after a time limit, depending on the expense of the algorithm.

Diagnostics

A server with slow-moving or frozen EJB invocations could be examined to determine what the call stack is on the waiters. Invocations could be selectively cancellable via an admin interface.