5 Replies Latest reply on Apr 22, 2005 8:42 PM by Derrick Koon

    Migration show stopper: Sticky database connections ?

    Derrick Koon Newbie

      We are migrating from Weblogic to JBoss 4.01 SP1. The DBMS is MS SQL 2000. We would have almost cutover it to production but we are blocked by a show stopper.

      Our applicatin supports users from different companies. Each company has its separate datasource. The sign-in userid contains the name of the company, and the application will use it to get a database connection from the right datasource.

      The symptom is: after running the application for a few hours, suddenly, userA of companyA will see data from companyB. This is of course very scary!

      We try to diagnose this and can think of 3 possible problems:

      1) JDBC driver has bugs - we have been using jTDS 0.71 but we also downloaded and tried jNetDirect's JSQLDirect. We were able to repeat the problem with both drivers, so we can rule out JDBC driver bugs.

      2) Our code has bugs - but this is the same code we ran on weblogic for the last two years. The only thing I changed to migrate to JBoss in order to get datasource was to add "java:" as a prefix to the datasource JNDI string. The chance is slim for bugs on our side.

      3) Is there any possibility that connection objects in JBoss can be sticky about the datasource they are associated with? It seemed to us that when we try to obtain a connection associated with datasource for companyA, we were given a connection associated with datasource for companyB.

      Can someone think of any bugs or configuration that we should know of?

      Appreciate the help because our migration is hanging in the balance...

      Thanks

        • 1. Re: Migration show stopper: Sticky database connections ?
          Scott Stark Master

          File a bug report in jira with the datasource configurations and example usage of the datasource where the data gets mixed up.
          http://jira.jboss.com/jira/browse/JBAS

          Enable trace level logging on the org.jboss.resource category in the conf/log4j.xml to determine what is going on in the jca layer:



          • 2. Re: Migration show stopper: Sticky database connections ?
            Christos Kokotsis Newbie

            quick suggestion that may be way off the mark but such behavior would occur as a result of ejb instances not having their member values re-initialised when retrieved from the instance pool.

            eg>

            1. retrieve instance of company bean from pool and populate with company A data.

            2. passivate and return bean to instance pool

            3. retrieve instance of company bean (previously populated with company A data) and populate with company B data.

            if company B data partial, and subject to incorrect ejb coding, company bean B will have old values still populated from previous company A population. This will be seen after some time as bean instances within the pool are re-used.

            Why u wouldn't see this b4 under web logic don't know. If this is the fix let me know.


            • 3. Re: Migration show stopper: Sticky database connections ?
              Adrian Brock Master

               

              "scott.stark@jboss.org" wrote:
              File a bug report in jira with the datasource configurations and example usage of the datasource where the data gets mixed up.
              http://jira.jboss.com/jira/browse/JBAS

              Enable trace level logging on the org.jboss.resource category in the conf/log4j.xml to determine what is going on in the jca layer:

              <category name="org.jboss.resource">
              <priority value="TRACE" class="org.jboss.logging.XLevel"/>
              </category>


              NO. HE SHOULD USE SEARCH OR READ THE DOCUMENTATION ABOUT JCA
              SECURITY CONFIGURATION.

              I answered this question earlier this month. I'm not going to repeat myself.
              The purpose of this forum is not to repeatedly provide the same answers to lazy users.

              Where's my "move redundant post to lazy users forum" button I have been asking for? :-)

              • 4. Re: Migration show stopper: Sticky database connections ?
                Adrian Brock Master

                OK, I relented and added it to the FAQ, along with the other common error.
                I doubt this will stop people still posting the question to the forums :-(

                http://www.jboss.org/wiki/Wiki.jsp?page=FAQJCASubPooling

                • 5. Re: Migration show stopper: Sticky database connections ?
                  Derrick Koon Newbie

                  It happens ckokotsis is correct. Our problem was due to an incorrect ejbLoad() coding where we did not refresh state after the first time the EJB was loaded.

                  The reason this incorrect ejbLoad() caused our symptom is that when user of
                  companyA signed in, JBoss went to cache/bean pool to get one existing
                  instance. It happened that there was a companyEJB available but it was used as
                  companyB before with companyB data. To change it to companyA, JBoss fired
                  ejbActivate() which in our code correctly assigned it the primary key of
                  companyA. Then JBoss fired ejbLoad() which in our code incorrectly refused to
                  reload data (because it loaded data once when it was first used as companyB).
                  Even though the key is companyA, the data is companyB!

                  The reason why this code had been working on the Weblogic side was likely due
                  to differences in EJB container implementation between the two application
                  servers. It seems like Weblogic does not trust programmers refreshing the
                  state in ejbLoad() that it resets all instance variables when it trys to reuse
                  an EJB from cache/bean pool. Anyway, if we would have coded ejbLoad()
                  correctly this symptom should have happened.

                  I fixed this problem on April 1st by forcing ejbLoad() to reload data everytime.

                  We tested it many times since and the symptom had disappeared.