I am wondering if a new thread is created for each ObjectGrid grid partition when associating a loader instance to a partition. I am trying to access a URL resource using JNDI look up within the preloadMap(...) method of my Loader plug-in but seeing this exception. I have made sure that the URL resource name and the JNDI name on the resource are all correct. I am running ObjectGrid on the WebSphere application server.
NMSV0310E: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. Exception stack trace:
javax.naming.ConfigurationException
Thinking that the ObjectGrid can be run in a standard J2SE JVM and a partition lives in a "grid container" as opposed to a Web or EJB container, I am wondering if the JNDI lookp is supported within any ObjectGrid plug-in. Am I missing anything here?
The Loader is not invoked on an EJB or Web container thread. It is invoked on an ORB thread, outside the purview of the container. It therefore has non J2EE context available on it.
Some customers have used a StartupBean or Servlet initializer to look-up the resource, and store it in a static variable. The EJB/Servlet has to be in the same module of the eXtreme Scale configuration (if using auto-starting containers), or the object you are using to cache the variable has to be visible to the xs container module and EJB/Servlet module.
The loader, when initialized, can then look for this variable and use it. Note that this only works for simple resources such as property files and some datasources. Several other resources require that it be invoked within the scope of a J2EE container thread.
There is actually a better way that I forgot about.
The Asynchronous Beans WorkManager allows you to create a WorkWithExecutionContext object. So instead of looking-up the java:comp resource on your EJB/Servlet thread, you look-up a WorkManager and call the create(Work work) method. Then store the resulting WorkWithExecutionContext object in a static. When your loader is called, call the WorkManager.doWork(Work w) method to run your work within the J2EE context of the EJB/Servlet that created WWEC in the first place.
So, in a nutshell:
1. Create a Work implementation that calls your Loader. You can use a Java proxy to do this. (call it the LoaderProxy)
2. Create a startup bean or Servlet with a contextlistener or init method and set it to auto-start.
3. In your application, create a resource environment reference to the default WorkManager (wm/default)
4. In the start() or init() method, lookup the default WorkManager; java:comp/wm/default
5. Instantiate your LoaderProxy Work and create a WorkWithExecutionContext object: workManager.create(loaderProxy);
6. Store the WorkManager instance insdie the LoaderProxy.
7. Store it in a static variable that your Loader has access to.
8. In your Java proxy implementation have it call the WorkManager.doWork(loaderProxy) method... this will automatically swithch the thread context to the J2EE context that created the WWEC.
Tags
Use the search field to
find all types of content in My developerWorks with that tag.
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular type of content or application that you're viewing.
My tags shows your tags for this particular type of content or application that
you're viewing.
