Recursive container-managed methods on Stateless beans
-------------------------------------------------------
Key: OPENEJB-1302
URL: https://issues.apache.org/jira/browse/OPENEJB-1302
Project: OpenEJB
Issue Type: Improvement
Components: container system
Reporter: David Blevins
If a stateless bean invokes itself via the business interface (see below);
public static interface RecursiveLocal {
public void retry(int i);
}
@Stateless
public static class RecursiveBean implements RecursiveLocal {
private SessionContext sessionContext;
public void retry(int i) {
if (i <= 0) return;
RecursiveLocal me =
sessionContext.getBusinessObject(RecursiveLocal.class);
me.retry(i - 1);
}
}
... this call essentially goes back to the pool and waits for another bean to
become available. If a bean does this recursively, then eventually the pool
could drain. At that point the bean will lock, holding all the instances,
until the AccessTimeout kicks in -- or deadlock if AccessTimeout is -1 which
means wait forever.
An improvement would be to put the stateless instance on the thread with a
thread local and a weak reference. Then instead of checking the pool first, we
would check the thread local for an already in use instance on the thread.
Great care would have to be taken to clear out the thread local. The
ThreadContext might be the best place to store such a thing. As well great
care would have to be taken to ensure that the instance isn't immediately
destroyed if it is still in use up the stack -- destruction would have to be
delayed. As well we would have to know not to check the bean instance back
into the pool if we obtained it from the thread local.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
