Question using Java API in a multi threaded application for MDX queries

Question

Currently I’m building a web application that makes a lot of MDX calls using the Essbase Java API. Each time we run an MDX call we basically run the following code:
IEssbase ess = IEssbase.Home.create(IEssbase.JAPI_VERSION);
IEssDomain dom = ess.signOn(userName, password, false, null, "embedded");
IEssCubeView cv = cv=dom.openCubeView("view", hostName, appName, cubeName);
IEssOpMdxQuery op = cv.createIEssOpMdxQuery();
op.setQuery(false,mdx,false,IEssOpMdxQuery.EEssMemberIdentifierType.NAME);
cv.performOperation(op);
IEssMdDataSet mddata = cv.getMdDataSet();
cv.close();
My questions is, is this the correct way to use the API in multi threaded environment where many users may be hitting the application at the same time? For every request do I need to create a separate IEssbase object and sign on to an IEssDomain? Or can I use a single IEssbase and IEssDomain object for the entire application? If not should I call the IEssDomain.signOff() method after each user’s request has completed? Which of the above objects are thread safe? I’m using Essabae 9.3.1. Any insight would be really appreciated.
Thanks
David

Answer 1

Thanks for the input friend,
I should have mentioned that in my application all
connections to Essbase use the same user name and
password so the filtering isn’t a concern. This is my
first Java application using Essbase has a data
source, I’m used to connecting to various SQL
databases and I always use a connection pool, how is
connection pooling handled in the Essbase java API?I'm not sure what happened to it since I never used it, but there used to be something called the High Availability Services or something that was essentially a connection pool for Essbase JAPI connections, but it required an extra license.
Since you don't care about identity (everyone has full access to everything), you can create your own connection pool, but you'll have to manage your multithreading yourself. Its been this way since the beginning. The C API isn't/wasn't thread-safe either (we tried).