Using EJBContext getContextData - is this safe?

Question

I am planning to use EJBContext to pass some properties around from the application tier (specifically, a message-driven bean) to a persistence lifecycle callba

Answer 1

I think in general the contract of the method is to enable the communication between interceptors + webservice contexts and beans. So the context should be available to all code, as long as no new invocation context is created. As such it should be absolutely thread-safe.

Section 12.6 of the EJB 3.1 spec says the following:

The InvocationContext object provides metadata that enables interceptor methods to control the behavior of the invocation chain. The contextual data is not sharable across separate business method invocations or lifecycle callback events. If interceptors are invoked as a result of the invocation on a web service endpoint, the map returned by getContextData will be the JAX-WS MessageContext

Furthermore, the getContextData method is described in 4.3.3:

The getContextData method enables a business method, lifecycle callback method, or timeout method to retrieve any interceptor/webservices context associated with its invocation.

In terms of actual implementation, JBoss AS does the following:

public Map getContextData() {
    return CurrentInvocationContext.get().getContextData();
}

Where the CurrentInvocationContext uses a stack based on a thread-local linked list to pop and push the current invocation context.

See org.jboss.ejb3.context.CurrentInvocationContext. The invocation context just lazily creates a simple HashMap, as is done in org.jboss.ejb3.interceptor.InvocationContextImpl

Glassfish does something similar. It also gets an invocation, and does this from an invocation manager, which also uses a stack based on a thread-local array list to pop and push these invocation contexts again.

The JavaDoc for the GlassFish implementation is especially interesting here:

This TLS variable stores an ArrayList. The ArrayList contains ComponentInvocation objects which represent the stack of invocations on this thread. Accesses to the ArrayList dont need to be synchronized because each thread has its own ArrayList.

Just as in JBoss AS, GlassFish too lazily creates a simple HashMap, in this case in com.sun.ejb.EjbInvocation. Interesting in the GlassFish case is that the webservice connection is easier to spot in the source.