ThreadlocalPool synchronizes on the backing pool while creating a new EJB instance, which isn't really necessary, and this can potentially lead to a deadlock if the EJB's constructor involves any other locks and something holding that lock tried to get a EJB instance from the pool. For example this can occur if the EJB constructor looks up an object using Spring, and another thread is already accessing the Spring ApplicationContext and it needs to get an EJB from the pool.

While ThreadlocalPool can't cause any problems by itself, it requires certain behaviour from the end-user code, it would be nice is it could avoid the problem.

ThreadlocalPool does three types of operations inside the "synchronized (this.pool)" block, which I believe dont't actually require it:

• Calls get/set on currentBeanContext - a ThreadLocal instance it is already thread-safe
• Uses the inUse variable - this could be replaces with an AtomicInteger since it does not need to remain consistent with the EJB instances
• Calls to create() and destroy() - these are not protected by a synchronisation block in other implementations, so is presumably unnecessary