Application Server Solutions for Microsoft IIS and ASP.NET
       solutions   products   partners   company   support   downloads         store
BlueDragon Self-Help: FAQ
Back to Search >  Back to Search Results

Faq ID 350
Product ServletExec
Category DataSource, JDBC, Session Tracking
Question How do I use the JdbcSessionManager that comes with ServletExec 5.0 and higher?
Answer

  1. Install & setup your database. The most current list of supported databases can be found in SE FAQ #349
  2. NOTE: This step does NOT involve ServletExec at all.
    Obtain a JDBC driver for your database. Most all drivers come with some simple examples in the form of standalone, command-line, java applications. You need to run some of them to ensure that you can:
    • connect to the database and do a simple Select query
    • use one of the driver's javax.sql.DataSource implementations (each "brand" of driver has it's own set of DataSource implementations and it's own set of jdbc properties that are used to tell the driver/datasource how to connect to the database, so you'll need to read the documentation that came with your driver and study the examples that came with your driver and make sure you understand how to use it).
      For example: If your JDBC driver is New Atlanta's JTurbo, then an explanation of the various DataSource implementations it provides can be found in JT FAQ #123
      And if you were using JTurbo, you'd find that it comes with several command-line examples. One of them is named "DataSourceExample.java" which creates and configures a DataSource object with this code:
                com.newatlanta.jturbo.driver.DataSource ds = new com.newatlanta.jturbo.driver.DataSource();
      			
      	  // Configure the data source
      	  ds.setServerName( server );
      	  ds.setDatabaseName( database );
      	  ds.setUser( username );
      	  ds.setPassword( password );
               

      Once a Datasource is created, code can simply use it directly to access the database and perform queries. Or the Datasource could (optionally) be stored in a JNDI Context like this:
                  InitialContext ctx = new InitialContext();
                  ctx.bind( "jdbc/testds", ds );
                 

      Then (presumably later on) the Datasource could be "looked up" using code like this:
                   InitialContext ctx = new InitialContext();
                   DataSource ds = (DataSource)ctx.lookup( "jdbc/testds" );
       
                   //now we can use the DataSource
                   ResultSet rs = ds.getConnection().executeQuery("Select * from mytable");
                 

      The storing & looking up of a Datasource using a JNDI context as described above is useful in a "shared" environment such as an Application Server (ServletExec for example). When you define a Datasource inside an Application Server, typcially the Application Server takes care of placing it into a JNDI context, so that all code running inside the app server can get a reference to the Datasource by simply looking it up.
  3. Once you are comfortable with using your JDBC driver, and you've confirmed that you can do so successfully, you are ready to use it inside ServletExec. Place the drivers's JAR file into the Main/global classpath of ServletExec. You can't simply place the driver's JAR file into the WEB-INF/lib folder of your webapp since the next step requires the driver to be on the Main/global classpath. You'll need to restart SE before global classpath changes will take effect.
  4. Use the SE Admin UI to add a new DataSource. For this step you should use what you learned when you ran the standalone Java Application examples. You may also find the chapter about DataSources (in the SE User Guide) to be useful here. After you've added the datasource, you'll see that ServletExec will introspect the Datasource implementation class that you specified and display all the possible properties it provides. You should configure these properties as needed/required for your given DataSource. Again... if you don't know what the property names mean, or what values they should have then you must read the documentation that came with your driver, and consider studying any examples that came with your driver (examples which use a DataSource might be good to study) so that you can see how to use one properly.

    ServletExec will take care of storing the Datasource implementation into a JNDI context so that the JdbcSessionManager code can simply look it up & use it. See the Help pages of the SE admin UI for more information on configuring a Datasource.

    The name you give your datasource can be any name you choose. However, by default the JdbcSessionManager expects the name of the Datasource to be "JTurbo_SQLServer_DataSource". If you give your datasource any other name, then you'll need to edit your webapp's copy of the jdbcSessionManager.properties file to reflect the name you used. For this, please see the next step.
  5. Extract a copy of the jdbcSessionManager.properties file out of the ServletExecXX.jar file.
    Place the copy into the /WEB-INF/classes folder of your webapp, preserving the folder structure so that you have:
    /WEB-INF/classes/com/newatlanta/servletexec/session/jdbcSessionManager.properties.
    This file is fully documented & may be used to configure your webapp's use of the JdbcSessionManager.
  6. Use the SE Admin UI to turn on ServletExec Extensions for your webapp.
  7. Open the Admin UI for your specific webapp, and access it's session tracking page. There you'll see that you can specify the Manager Class Name. Set it to be:
    com.newatlanta.servletexec.session.JdbcSessionManager
  8. Reload your webapp, and then go look in your database to confirm that it now has a sessions table.
  9. All webapps that are:
    1. Accessed using the same hostname
    2. -AND-
    3. configured to use the JdbcSessionManager with a Datasource that points to the same database
    4. -AND-
    5. deployed using the same context path
    will effectively be sharing sessions.
    In this way, you can deploy the same webapp onto multiple instances of SE (duplicate/redundant deployments), and do non-sticky load balancing of the webservers behind which the SE AS instances are running, without any session data loss between the various app deployments.
  10. If problems occur, check ServletExec.log for clues, and consider turning on debugging for the JdbcSessionManager by editing the jdbcSessionManager.properties file so that jdbc.debug=true

More information about the JdbcSessionManager can be found in the ServletExec User Guide.



   
company media information terms of use privacy policy contact us