glassfish
  1. glassfish
  2. GLASSFISH-5620

Using wrong JDBC Connection after deploy

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 9.1peur2
    • Fix Version/s: V3
    • Component/s: entity-persistence
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      5,620

      Description

      My GlassFish instance uses two JDBC resources (different databases) and drives
      two applications. So each application is bound to its own JDBC resource.

      Unfortunately, by incident I have bound both applications to the same JDBC
      resource when I redeployed a new version of one of the applications. As a
      result, certainly the mis-bound application did not work.

      So I fixed the WAR once my, and did another redeploy. Strange but true, still it
      complained to not find its tables!

      Then, I undeployed the WAR, and deployed it from scratch. But STILL it did not
      find its tables!

      Then, I did nothing else but to stop and start the GlassFish instance (without
      any other action) – and THEN it was bound to the right JDBC resource!

      That's pretty weird. It looks as if the undeploy doesn't really "forget" the
      mis-bound JDBC resource, and just binds again to it when doing another deploy.
      That's scary!

        Activity

        Hide
        Jagadish added a comment -

        adding cc

        Show
        Jagadish added a comment - adding cc
        Hide
        Hong Zhang added a comment -

        How are you mapping the jdbc resource? Is it through injection (with a mapped
        name) or through deployment descriptor (with sun-web.xml)?

        Show
        Hong Zhang added a comment - How are you mapping the jdbc resource? Is it through injection (with a mapped name) or through deployment descriptor (with sun-web.xml)?
        Hide
        Hong Zhang added a comment -

        This is what I tried and I could not reproduce the problem, maybe it's different
        than your scenario.

        1. I created a simple war with a TestServlet referencing a jdbc resource. Then
        in the servlet processRequest method, I tried to print out the login timeout for
        that datasource.
        out.println("<h2> logintime out" + ds1.getLoginTimeout() + "</h2>");

        2. The first war I created, the jdbc resource is mapped to a non-existant jdbc
        resource:
        private @Resource(mappedName="jdbc/foo") DataSource ds1;
        And when I tried to access the TestServlet after the application is
        deployed, I got an expected NameNotFound exception for resource "jdbc/foo".

        3. I then created another war with same name, and the jdbc resource is mapped to
        the default glassfish jdbc resource:
        private @Resource(mappedName="jdbc/__default") DataSource ds1;

        4. I redeployed the war, and access the servlet, the servlet is printing out the
        information properly without giving any exceptions.

        I did not have to restart server.

        So could you let me know how to reproduce your problem and could you attach a
        test case?

        Show
        Hong Zhang added a comment - This is what I tried and I could not reproduce the problem, maybe it's different than your scenario. 1. I created a simple war with a TestServlet referencing a jdbc resource. Then in the servlet processRequest method, I tried to print out the login timeout for that datasource. out.println("<h2> logintime out" + ds1.getLoginTimeout() + "</h2>"); 2. The first war I created, the jdbc resource is mapped to a non-existant jdbc resource: private @Resource(mappedName="jdbc/foo") DataSource ds1; And when I tried to access the TestServlet after the application is deployed, I got an expected NameNotFound exception for resource "jdbc/foo". 3. I then created another war with same name, and the jdbc resource is mapped to the default glassfish jdbc resource: private @Resource(mappedName="jdbc/__default") DataSource ds1; 4. I redeployed the war, and access the servlet, the servlet is printing out the information properly without giving any exceptions. I did not have to restart server. So could you let me know how to reproduce your problem and could you attach a test case?
        Hide
        mkarg added a comment -

        Mapping is done by persistence.xml:

        <persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
        <persistence-unit name="QUIPSY" transaction-type="JTA">
        <provider>oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider</provider>
        <jta-data-source>jdbc/RH/QUIPSY/4</jta-data-source>
        <class>mk.jpa.Article</class>
        <class>mk.jpa.Person</class>
        <properties>
        </persistence-unit>
        </persistence>

        JTA-Datasource "jdbc/RH/QUIPSY/4" was created as JDBC Resource manually using
        the admin GUI of GlassFish, referencing one of my JDBC Pools.

        Show
        mkarg added a comment - Mapping is done by persistence.xml: <persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0"> <persistence-unit name="QUIPSY" transaction-type="JTA"> <provider>oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider</provider> <jta-data-source>jdbc/RH/QUIPSY/4</jta-data-source> <class>mk.jpa.Article</class> <class>mk.jpa.Person</class> <properties> </persistence-unit> </persistence> JTA-Datasource "jdbc/RH/QUIPSY/4" was created as JDBC Resource manually using the admin GUI of GlassFish, referencing one of my JDBC Pools.
        Hide
        mkarg added a comment -

        My scenario was different:

        There is a EAR running already containing several EJB-JARs and RARs. That is
        using JDBC Resource A.

        Then I am adding my WAR, pointing to JDBC Resource A, too.

        After deployment I run a test so the WAR complains that it does not find it's
        tables (those are not contained in JDBC Resource A, but in a different resource).

        Now adding JDBC Resource B.

        Now doing redeploy or undeploy/deploy of the WAR.

        When now starting another test, it STILL uses Resource A instead of Resource B.

        Also it might be interesting that I am using Windows XP Pro on my host?

        I cannot provide more than this, since I do not know how to set up a test case
        for that?

        Show
        mkarg added a comment - My scenario was different: There is a EAR running already containing several EJB-JARs and RARs. That is using JDBC Resource A. Then I am adding my WAR, pointing to JDBC Resource A, too. After deployment I run a test so the WAR complains that it does not find it's tables (those are not contained in JDBC Resource A, but in a different resource). Now adding JDBC Resource B. Now doing redeploy or undeploy/deploy of the WAR. When now starting another test, it STILL uses Resource A instead of Resource B. Also it might be interesting that I am using Windows XP Pro on my host? I cannot provide more than this, since I do not know how to set up a test case for that?
        Hide
        Hong Zhang added a comment -

        As the problem happens with the persistence unit (and not with the simple
        reference to jdbc resource), assign to persistence team to take a look.

        Show
        Hong Zhang added a comment - As the problem happens with the persistence unit (and not with the simple reference to jdbc resource), assign to persistence team to take a look.
        Hide
        Mitesh Meswani added a comment -

        I was not able to reproduce the issue. Here is what I tried.
        1. Deploy a ear that has reference to Resource A
        2. Run the app so as to access Resource A
        3. Deploy a war using JPA with reference to Resource A
        4. Run the app so as to access Resource A and get error for table not existing
        5. Redeploy the war with reference to Resource B where the table exist
        6. Run the app - Everything works fine

        If you are able to reproduce the issue, please open the issue listing steps to
        reproduce the issue

        Show
        Mitesh Meswani added a comment - I was not able to reproduce the issue. Here is what I tried. 1. Deploy a ear that has reference to Resource A 2. Run the app so as to access Resource A 3. Deploy a war using JPA with reference to Resource A 4. Run the app so as to access Resource A and get error for table not existing 5. Redeploy the war with reference to Resource B where the table exist 6. Run the app - Everything works fine If you are able to reproduce the issue, please open the issue listing steps to reproduce the issue

          People

          • Assignee:
            Mitesh Meswani
            Reporter:
            mkarg
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: