title: Using EJBContext getContextData - is this safe?
body: <p>I am planning to use <code>EJBContext</code> to pass some properties around from the application tier (specifically, a message-driven bean) to a persistence lifecycle callback that cannot directly be injected or passed parameters (session listener in EclipseLink, entity lifecycle callback, etc.), and that callback is getting the <code>EJBContext</code> via JNDI.</p>
  
  <p>This appears to work but are there any hidden gotchas, like thread safety or object lifespan that I'm missing?  (Assume the property value being passed is immutable like String or Long.)</p>
  
  <p>Sample bean code</p>
  
  <pre><code>@MessageDriven
  public class MDB implements MessageListener {
     private @Resource MessageDrivenContext context;
  
     public void onMessage(Message m) { 
        context.getContextData().put("property", "value");
     }
  }
  </code></pre>
  
  <p>Then the callback that consumes the EJBContext</p>
  
  <pre><code>public void callback() { 
     InitialContext ic = new InitialContext();
     EJBContext context = (EJBContext) ic.lookup("java:comp/EJBContext");
     String value = (String) context.getContextData().get("property");
  } 
  </code></pre>
  
  <p>What I'm wondering is, can I be sure that the <code>contextData</code> map contents are only visible to the current invocation/thread?  In other words, if two threads are running the <code>callback</code> method concurrently, and both look up an <code>EJBContext</code> from JNDI, they're actually getting different <code>contextData</code> map contents?  </p>
  
  <p>And, how does that actually work - is the <code>EJBContext</code> returned from the JNDI lookup really a wrapper object around a <code>ThreadLocal</code>-like structure ultimately?</p>