Discussions

EJB design: Distributed Databases and entity beans

  1. Distributed Databases and entity beans (3 messages)

    Hi All
       We have a typical problem in here which needs certain explaining - :

       We have the following scenario :

       App Server - situated at Location A
       Database1 - situated at Location A
       Database2 - situated at Location B

       Database1 and Database2 have identical schema and different data.
       If a JSP user comes from location A ; my entity beans must use Database1 persistence and if a JSP user comes from location B ; my entity beans should use Database2 persistence. Is this scenario possible using CMP ; wherein the persistence is decided at run time .What can be the best architecture in this case.I want to stick with CMPs as far as possible.
       Any help would be appreciated.
       Regards ,
    Tim Lee
       
  2. Deploy the beans twice and use JNDI to differentiate between database1 abd 2?
  3. Hi Dimitri
       The method u suggested is going to be my last resort.I was thinking if someone can give me a better idea ;cause this seems to be a bit clumsy solution.
       Thanks
    Tim Lee
  4. Distributed Databases and entity beans[ Go to top ]

          Over the last week I've done a number of searches through various forums and have found a lot of people asking essentially the same question. What I have not found are any answers. Here's my guess. 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?

    Thanks,
    Tom