Java – use ejbcontext getcontextdata – is this safe?

I plan to use ejbcontext to pass some persistent lifecycle callbacks that cannot directly inject or pass parameters (session listeners in eclipse link, entity lifecycle callbacks, etc.) from the application layer (especially message driven beans), and the callback obtains ejbcontext through JNDI

This seems to be effective, but are there any hidden problems, such as thread safety or object life cycle, I'm missing? (assume that the property value passed is immutable, such as string or long.)

Sample bean code

@MessageDriven
public class MDB implements MessageListener {
   private @Resource MessageDrivenContext context;

   public void onMessage(Message m) { 
      context.getContextData().put("property","value");
   }
}

Then consume the callback of ejbcontext

public void callback() { 
   InitialContext ic = new InitialContext();
   EJBContext context = (EJBContext) ic.lookup("java:comp/EJBContext");
   String value = (String) context.getContextData().get("property");
}

What I want to know is, can I be sure that the content of the contextdata mapping is only visible to the current call / thread? In other words, if two threads run the callback method at the same time and both look for an ejbcontext from JNDI, they will actually get different contextdata mapping contents?

Moreover, how does this actually work - is ejcontext really a wrapper object around ThreadLocal structure returned from JNDI lookup?

Solution

I think in general, the contract of this method is to make communication between interceptor WebService context and bean possible Therefore, the context should be available to all code as long as no new call context is created Therefore, it should be absolutely thread safe

Section 12.6 of the EJB 3.1 specification states:

In addition, the getcontextdata method is implemented in 4.3 Description in 3:

In terms of practical implementation, JBoss as performs the following operations:

public Map<String,Object> getContextData() {
    return CurrentInvocationContext.get().getContextData();
}

Currentinvocationcontext uses the stack based on thread local linked list to pop up and push the current call context

See org jboss. ejb3. context. CurrentInvocationContext. The call context just lazily creates a simple HashMap, like org jboss. ejb3. interceptor. Invocationcontextimpl

GlassFish does similar things It is also gets an invocation, and the from an invocation manager also uses a stack based on thread local array list to pop up and push these invocation contexts again

The Javadoc implemented by GlassFish is very interesting here:

Just like JBoss as, GlassFish lazily creates a simple HashMap, in this case on COM sun. ejb. EjbInvocation. What is interesting about GlassFish is that web service connections are easier to find in the source