It seems to me that if you want to determine which database a user should hit at runtime there are only two ways to go.
First you could do it through the JNDI name of the Beans. At launch a user profile of some sort would pass some part of the JNDI name matching the database the user should access. This sting could be appended to the JNDI name of the Bean. In this scenario you may be able to have one set of deployed EJB jar files for your session beans. Entity beans, however, would require a separate jar file for each database. This is because their XML files must point to different data sources. With this approach you have multiple versions of XML and jar files to maintain. If you make a change you have to rebuild for every customer. On the other hand the differences are trivial and you can handle all your users through one domain.
Another option, at least with Weblogic, is run a separate domain for each database. Again user profile passes your application which URL to hit for the users domain/database. All domains would use the same Data Source name. Their Connection Pool would point to different databases. This would allow all domains to use the same set of deployed EJB jar files. You only have one set of XML and jar files to maintain but you have to run multiple domains.
This is not an uncommon scenario. To have to maintain a separate set of XML/jar files because of a single hard coded value seems overkill. On the other hand what are the costs for each additional domain? It seems this could be addressed in a better way. Is this a major hole in EJB?
We are developing an EJB app that requires this functionality....
We use only session beans... The following steps explain how we solve this problem:
1. We have something called as an appl_id (a database indicator). This appl_id comes as an element in input to our system (xml input).
2. This directly represents the database connection pool name (data source).
3. we set up the weblogic properties to add the TXDataSource for the each db pool (name same as appl_id)
4. We do a JNDI lookup for the datasource using this appl_id dynamically (from the input appl_id). Since the container will set up the pool as a JNDI entry..
5. We do not declare any resource refs for the pools in the bean's deployment descriptors..
But I am still unclear how to handle this with entity beans..
The following are the list of concerns/issues I faced for
an EJB app serving multiple instances of a database..
1. Most importantly as you mentioned handling entity beans..
2. If you want JMS message persistence... If you want this persistence with multiple databses...You might not be able to do that. (refer to discussion topic: [How to define multiple JMS connection pools] in theserverside.com)
3. Isolating logging while using same beans to serve multiple databases...
4. IMHO kind of falls away from EJB model...Let me explain why I think it drifts away from EJB model: EJB app is modelled on a single system (SysMain, could be a database). EJB app could extend this system and also could interact with this sytem. During this process it could get information or help from other systems (SysHelp1, SysHelp2 etc could be other databases). But EJB model doesn't support modelling of multiple instances of a system (SysMain). In other words you should not have two instances of SysMain being served by a single EJB app, you should ideally have two instances of EJB app. I could be totally wrong on this but I just expressed my thought process. I would really appreciate yours and other EJB experts' input.
I tried my best but could not get any documentation or information on this issue.
Thanks a lot,