5 Replies Latest reply on Nov 23, 2005 10:25 AM by spoonman464

    accessing different instances of a database

    Hideki Mae Newbie

      To all:
      System information: JBoss-4.0.0, Windows XP Pro, Database: Oracle 9i
      I apologize in advance if I posted this in the wrong forum.
      I?m trying to solve a problem where I have a web application that needs to access two different instances of a database (ex. we call the instances dwm1 and dwm2) that reside on the same machine. These two databases have the same exact database schema but the data might be different. The reason why there are two different instances is because a company was acquired and the database is kept on the same machine but the data is kept separate. The data that I would get from my web application has to be kept separate.
      Since the database schema is the same, I have one application EAR file which I would like to reuse for the two instances.
      To make a distinction between the two, I was thinking of having two different contextroot so it would access the two different instances.

      Is there a way to do this? If I were to make different EAR files and deploy it, it will probably cause conflict due to duplicate beans.

      Thanks you.

        • 1. Re: accessing different instances of a database
          Wessel de Roode Newbie

          Coudn't you just move the beans into a different jndi directory ?
          think that might work

          Wessel de Roode

          • 2. Two datasources, two different JNDI names
            spoonman464 Newbie

            I realize that I'm not giving enough information right now for you to actually DO what I suggest, but I might be able to help with some details if you are interested in this approach.

            In JBoss, you can use XML files in the \deploy directory to declare datasources, for example, a file called mysql-ds.xml might contain the following:


            This file declares a My SQL database called "test" and gives it a JNDI name of "MySqlDS".

            It seems to me that you could create two files like this one. Each file would declare a different datasource and associate a different JNDI name. I think you might even be able to declare BOTH in the same file as there is a "datasources" node but I'd have to check on that.

            Anyway, if you have 2 datasources each with different JNDI names, you could use two copies of your EAR, each referring to the different datasource's JNDI names.

            The question you asked about using different context roots doesn't seem to solve the problem of using different databases. Declaring different datasources with different JNDI names might.

            Does this approach sound interesting to you?


            • 3. Re: accessing different instances of a database
              Hideki Mae Newbie

              Thank you for your replies.
              I tried deploying two different EAR files with two different datasources. The two EAR file has one bean that have the same name. When I tried to deploy it on the same machine, it returned an error
              For my problem, since the database schema is the same, I would need to rename all my beans and this could easily lead to maintenance issues.
              For now, I asked my manager if there was another machine where I can install JBoss and keep the EAR files separate. This way the URL would become:

              • 4. I think there is a deployment descriptor for this problem
                spoonman464 Newbie

                In the jboss.xml file there is a "loader-repository" element designed to permit two EARs with similar contents to be deployed without interference.

                The modules inside an application often contain compiled Java classes. EJB-JARs always have classes in them. Maintaining uniqueness among class names across an entire application server can be managed with strict enforcement of naming structures among the developers. In general, however, it is probably best to ensure that the Java classes contained inside an EAR or its modules will not interfere with other classes in other applications and modules that have the same names.

                For example, it is possible for two different applications to have classes with the same name. In one application, there may be a Java class named "com.spoonware.training.CustomerBean". In another application that also deals with products, there could be another Java class with the same name. If these classes are not scoped at the EAR level, they are automatically scoped at the server level. As a result, these two applications will interfere with each other. It is common for this situation to exist when multiple versions of the same application are deployed on a test or development server.

                To prevent this interference, the "loader-repository" descriptor must be added to the jboss.xml for each application. For example, assume that the applications are found in two EARs: customerApp1.ear and customerApp2.ear. Both applications have ejb-jars which contain numerous Java classes with names in common between the two EARs. To ensure that each set of classes do not interfere with each other, the server-specific deployment descriptors should have the following entries respectively:

                In customerApp1.ear:


                In customerApp2.ear:

                The value of this parameter has two parts separated by a colon. To the left of the colon, the value does not matter as long as it is unique on the application server and is a valid JMX ObjectName. The part to the right of the colon must be in the format "loader=earfilename" where "earfilename" is the name of the current EAR.

                I don't for sure if this approach will solve your conflicts problem but I've done it this way in the lab in the past and it solved mine.

                Give it a try and let us know what you get.


                • 5. loader-repository stuff
                  spoonman464 Newbie

                  Oops! It looks like I made a mistake. In the above document, I should have said that the <loader-repository> stuff goes in the "jboss-app.xml" file in the META-INF folder and not in the jboss.xml file.