Fatal bug with shared JDBC Session Persistence

Question

We are attempting to launch a three-tier site with two clusters, one at the
          web layer (JSP/servlet/images) and a separate cluster at the app server
          layer (EJBs). We are running WebLogic server 4.5.1 Service Pack 8 on Solaris
          2.7. In production we use Solaris JDK 1.2.1.04, and in development we use
          JavaSoft JDK 1.2.2. We are able to duplicate this problem with both JDKs. We
          are using the WebLogic kona/oracle driver for session persistence because
          the Oracle JDBC driver would not work for this purpose - we are using the
          Oracle OCI driver for our EJB persistence in a separate pool in the app
          server cluster.
          We attempted to configure our web cluster to work with in-memory session
          replication. We found the performance of the WebLogic proxy to be abysmal -
          causing a 5x to 10x performance degredation over shared JDBC persistence. We
          were running the proxy on WebLogic, which we were advised would be slow. Its
          performance is beyond slow, it is completely unusable and should NEVER be a
          recommended or even supported configuration. We do not wish to purchase
          separate licenses for iPlanet, refuse to run IIS in a production setting,
          and cannot use Apache until WebLogic 5.1, so we are stuck with shared JDBC
          persistence until we can upgrade to 5.1.
          Using JDBC session persistence with a shared persistent store amongst all
          the clustered web servers results in our users getting brand-new sessions
          populated with data from OTHER USERS' SESSIONS. This is very easy to
          replicate using the provided test JSP and java class. This behavior results
          in new users coming to the site and finding themselves logged in as other
          users.
          The test.jsp file simply accesses the session, prints out some information,
          and then adds a few values to the session. The JSP prints out the value of
          session.isNew(), the session's ID, and the number of values in the session
          space. If you hit this jsp with a new browser window, the session should be
          new, and the number of values should be zero.
          The test Java class hits a URL with this test.jsp file repeatedly, and
          checks to make sure that the session is empty. It keeps a counter of the
          number of hits which resulted in non-empty sessions and the total number of
          hits. Because this java class does not maintain cookie data of any kind and
          merely opens new HTTP connections, it should always receive a brand-new,
          non-empty session.
          When we set the JDBC session persistence property
          weblogic.httpd.session.persistentStoreShared=true and run the test, we see
          periodically see the test.jsp file receiving a brand-new (session.isNew() =
          true), yet non-empty (session.getValueNames().length != 0) session. This is
          extremely bad behavior and makes the shared JDBC session persistence setting
          worthless. We were able to duplicate this behavior with both a single server
          and multiple servers in a cluster.
          If we set weblogic.httpd.session.persistentStoreShared=false, then this test
          works fine. This also means that we cannot cluster web servers.
          To run the test, simply start a WebLogic instance using the provided
          properties file, put the jsp in the document-root somewhere, and then run
          SessionTest.java, providing the URL of the test JSP as the only command-line
          argument. You will need to modify the properties file to have the proper
          database settings and document-root. The java class will display a running
          tally of the number of hits, and the number of hits that result in
          non-empty, illegal sessions, with a total at the end.
          So, we are now in a position where we are completely unable to launch our
          site in a clustered, no-single-point-of-failure configuration. Obviously,
          clustering was one of the main reasons to choose WebLogic, and we are
          extremely distressed that we are unable to get this configuration to work.
          Any help would be appreciated.
          [web.standalone.properties]
          [SessionTest.java]
          [test.jsp]
          

Answer 1

I hope this is not too far fetched, but we are expieriencing a similar
          problem with jms (messages are mixed up between queues). This happens only
          if we are using message persistence in an oracle db (everything works ok
          when we are not using persistent messages). Could it be that there is a
          serious bug in the jdbc code/oracle driver code or connection handling
          (regarding multi threading)? This would explain that, whenever you use
          persistence with oracle databases, messages/sessions (or other) are mixed
          up.
          - Falk
          "Grant Kushida" <[email protected]> wrote in message
          news:[email protected]...
          > We are attempting to launch a three-tier site with two clusters, one at
          the
          > web layer (JSP/servlet/images) and a separate cluster at the app server
          > layer (EJBs). We are running WebLogic server 4.5.1 Service Pack 8 on
          Solaris
          > 2.7. In production we use Solaris JDK 1.2.1.04, and in development we use
          > JavaSoft JDK 1.2.2. We are able to duplicate this problem with both JDKs.
          We
          > are using the WebLogic kona/oracle driver for session persistence because
          > the Oracle JDBC driver would not work for this purpose - we are using the
          > Oracle OCI driver for our EJB persistence in a separate pool in the app
          > server cluster.
          >
          > We attempted to configure our web cluster to work with in-memory session
          > replication. We found the performance of the WebLogic proxy to be
          abysmal -
          > causing a 5x to 10x performance degredation over shared JDBC persistence.
          We
          > were running the proxy on WebLogic, which we were advised would be slow.
          Its
          > performance is beyond slow, it is completely unusable and should NEVER be
          a
          > recommended or even supported configuration. We do not wish to purchase
          > separate licenses for iPlanet, refuse to run IIS in a production setting,
          > and cannot use Apache until WebLogic 5.1, so we are stuck with shared JDBC
          > persistence until we can upgrade to 5.1.
          >
          > Using JDBC session persistence with a shared persistent store amongst all
          > the clustered web servers results in our users getting brand-new sessions
          > populated with data from OTHER USERS' SESSIONS. This is very easy to
          > replicate using the provided test JSP and java class. This behavior
          results
          > in new users coming to the site and finding themselves logged in as other
          > users.
          >
          > The test.jsp file simply accesses the session, prints out some
          information,
          > and then adds a few values to the session. The JSP prints out the value of
          > session.isNew(), the session's ID, and the number of values in the session
          > space. If you hit this jsp with a new browser window, the session should
          be
          > new, and the number of values should be zero.
          >
          > The test Java class hits a URL with this test.jsp file repeatedly, and
          > checks to make sure that the session is empty. It keeps a counter of the
          > number of hits which resulted in non-empty sessions and the total number
          of
          > hits. Because this java class does not maintain cookie data of any kind
          and
          > merely opens new HTTP connections, it should always receive a brand-new,
          > non-empty session.
          >
          > When we set the JDBC session persistence property
          > weblogic.httpd.session.persistentStoreShared=true and run the test, we see
          > periodically see the test.jsp file receiving a brand-new (session.isNew()
          =
          > true), yet non-empty (session.getValueNames().length != 0) session. This
          is
          > extremely bad behavior and makes the shared JDBC session persistence
          setting
          > worthless. We were able to duplicate this behavior with both a single
          server
          > and multiple servers in a cluster.
          >
          > If we set weblogic.httpd.session.persistentStoreShared=false, then this
          test
          > works fine. This also means that we cannot cluster web servers.
          >
          > To run the test, simply start a WebLogic instance using the provided
          > properties file, put the jsp in the document-root somewhere, and then run
          > SessionTest.java, providing the URL of the test JSP as the only
          command-line
          > argument. You will need to modify the properties file to have the proper
          > database settings and document-root. The java class will display a running
          > tally of the number of hits, and the number of hits that result in
          > non-empty, illegal sessions, with a total at the end.
          >
          > So, we are now in a position where we are completely unable to launch our
          > site in a clustered, no-single-point-of-failure configuration. Obviously,
          > clustering was one of the main reasons to choose WebLogic, and we are
          > extremely distressed that we are unable to get this configuration to work.
          > Any help would be appreciated.
          >
          >
          >
          >