David Lloyd created WFLY-6795:
---------------------------------
Summary: Introduce EJB "call stack" notion
Key: WFLY-6795
URL:
https://issues.jboss.org/browse/WFLY-6795
Project: WildFly
Issue Type: Enhancement
Components: EJB
Reporter: David Lloyd
h1. 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.
h2. 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.
h2. 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.
h2. 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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)