我认为一般而言，该方法的约定是启用拦截器+ Web服务上下文与Bean之间的通信。因此， 只要没有创建新的调用上下文
，该上下文应可用于所有代码。因此，它应该绝对是线程安全的。
EJB 3.1规范的第12.6节指出：
InvocationContext对象提供了使拦截器方法能够控制调用链行为的元数据。上下文数据不可在单独的业务方法调用或生命周期回调事件之间共享。如果在Web服务终结点上调用了拦截器，则getContextData返回的映射将为JAX-
WS MessageContext。
此外，在4.3.3中描述了getContextData方法：
getContextData方法使业务方法，生命周期回调方法或超时方法能够检索与其调用关联的任何拦截器/ webservices上下文。
在实际实现方面，JBoss AS执行以下操作：
public Map<String, Object> getContextData() { return CurrentInvocationContext.get().getContextData();}其中
CurrentInvocationContext使用基于线程本地链接列表的堆栈来弹出并推送当前调用上下文。
参见org.jboss.ejb3.context.CurrentInvocationContext。调用上下文只是懒惰地创建了一个简单的
HashMap，就像org.jboss.ejb3.interceptor.InvocationContextImpl中所做的那样
Glassfish做类似的事情。它还从调用管理器获得一个调用，该调用管理器还使用基于线程本地数组列表的堆栈来再次弹出并推送这些调用上下文。
GlassFish实现的JavaDoc在这里特别有趣：
该TLS变量存储一个ArrayList。ArrayList包含ComponentInvocation对象，这些对象表示此线程上的调用堆栈。不需要同步对ArrayList的访问，因为每个线程都有自己的ArrayList。
就像在JBoss
AS中一样，GlassFish也懒洋洋地
HashMap在com.sun.ejb.EjbInvocation中创建了一个简单的例子。在GlassFish案例中，有趣的是Web服务连接更易于在源中发现。
