Jaikiran,
I can not see how handing out the appropriate EJBClientContext solves this. I believe that EJBClientContext is the cause of this problem to the static usage in SELECTOR.
This is what we are currently doing using the JBOSS ejb client API to get around the multiple thread trashing SELECTOR in EJBClientContext.
For each server target (Unique by credentials and host name/Port), we are creating a new ConfigBasedEJBClientContextSelector which in turn creates an EJBClientContext. When we invoke an ejb method, some invoker code in JBOSS will call requireCurrent on the EJBClientContext which will trash any SELECTOR currently set if being invoked from a separate thread. Our code is wrapping the proxy returned the InitialContext.lookup to globally lock before preceeding with an ejb call. This naturally will cause the server to become a client (Really, a very expensive server) to become single threaded.
static class RemoteInvocationHandler implements InvocationHandler {
static Object globalLock = new Object();
private ContextSelector<EJBClientContext> selector;
private Object delegate;
public RemoteInvocationHandler(ContextSelector<EJBClientContext> selector, Object delegate) {
this.selector = selector;
this.delegate = delegate;
}
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
synchronized(globalLock) { // EVIL Code
EJBClientContext.setSelector(selector);
Object result = method.invoke(delegate, args);
return result;
}
}
}
Thank you for your prompt reply.