Использование EJBContext getContextData - это безопасно?

Я планирую использовать EJBContext для передачи некоторых свойств из уровень приложения (в частности, объектный компонент, управляемый сообщениями) для обратного вызова жизненного цикла персистентности, который нельзя напрямую ввести или передать параметры (прослушиватель сеанса в EclipseLink, обратный вызов жизненного цикла объекта и т. д.), и этот обратный вызов получает EJBContext через JNDI.

Кажется, это работает, но есть ли какие-то скрытые ошибки, например, thread saf ety или срок службы объекта, который мне не хватает? (Предположим, что передаваемое значение свойства неизменяемо, например String или Long.)

Пример кода bean-компонента

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

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

Затем обратный вызов, который использует EJBContext

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

Мне интересно, могу ли я быть уверен, что содержимое карты contextData видно только текущему вызову / потоку? Другими словами, если два потока одновременно выполняют метод обратного вызова , и оба ищут EJBContext из JNDI, они фактически получают различное содержимое карты contextData ?

И как это на самом деле работает - действительно ли EJBContext , возвращенный из поиска JNDI, действительно является объектом-оболочкой вокруг структуры, подобной ThreadLocal , в конечном счете?