[OPENEJB-1302] Recursive container-managed methods on Stateless beans

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: container system
• Assignee: Unassigned
• Reporter: David Blevins
• Created: 22/Jun/10 01:36
• Updated: 22/Jun/10 01:36

Description

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.