Note that there are some explanatory texts on larger screens.

plurals
  1. POUsing EJBContext getContextData - is this safe?
    text
    copied!<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>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload