6.8 Session pooling

< Day Day Up >

In this exercise you will create a very simple example of a Domino session pool, based on the open source Jakarta Commons pool implementations.

The Jakarta Commons product has a pool component ready to extend. It is very easy to use and will give the portlet developer excellent results. To obtain more information on the Jakarta Commons pool, see the following Web site:

http://jakarta.apache.org/commons/pool/

To work through this example, download the Commons Pool code from the Web page and unzip the file to a folder that we will reference as COMMONS_POOL_HOME.

Note

The example of this pool can be downloaded from the on-line resources of this redbook. Refer to Appendix B, "Additional material" on page 421 for instructions on downloading the example code.

At a high level, this example will:

Create a Domino Session Pool factory
Create a sample Java client which tests your pool
Analyze the performance of your pool compared with a create-destroy approach for Session Management

The detailed steps are in the following sections.

Domino Session Pool Factory Java class

Start by creating the Domino Session Pool Factory. You will extend the BasePoolableObjectFactory class that comes with the Jakarta Commons pool, and define in your factory how a Session is created and destroyed.

Open WebSphere Studio 5.
Switch to the Java perspective.
Select the File → New → Project menu.
Select Next.
Name the project DominoSessionPool and click Next.
In the Java Settings dialog in the Source tab, change the "Use the project as source folder" to "Use source folders contained in the project," then click Create New Folder, enter src, and click OK. This is shown in Figure 6-17.

Figure 6-17: Creating DominoSessionPool project
A new dialog confirms the creation of a new build output directory to DominoSessionPool/bin. Click Yes.
Switch to the Libraries tab, and add the following external JARs:
1. Add NSCO.jar from the DOMINO_HOME\data\Domino\java directory.
2. Add Notes.jar from the DOMINO_HOME directory
3. Add commons-pool.jar from the COMMONS_POOL_HOME\commons-pool-1.0.1 directory
The libraries tab should look like Figure 6-18 on page 344.

Figure 6-18: Creating DominoSessionPool project- Adding Libraries
Click Finish.
Select the newly created DominoSessionPool project, right-click the src folder, and select New → Package.
Name the package com.ibm.itso.sg247004.DominoSessionPool; click Finish.
Right-click the newly created package and select New → Class.
Name the class DominoSessionFactory and extend the BasePoolableObjectFactory as shown in Figure 6-19. Click Finish.

Figure 6-19: Creating the DominoSessionFactory
The DominoSessionFactory should pop up. Add the following import statement at the beginning of the class:
```
    import lotus.domino.*; 
```

Replace the make() method with the following code:

    public Object makeObject() throws Exception {       System.out.println("\t DomSessFact: Creating Domino Session...");       Session s = NotesFactory.createSession(                       "<servername>","<username>","<password>");       System.out.println("\t DomSessFact:                              Domino Session successfully created !");       return s;    }

Add a destroyObject() method with the following code:

    public void destroyObject(Object arg0) throws Exception {       System.out.println("\t DomSessFact: Destroying Domino Session...");       Session s=(Session)arg0;       s.recycle();       super.destroyObject(arg0);       System.out.println("\t DomSessFact: Domino Session destroyed                             successfully !");    }

Save and close the DominoSessionFactory class.

Client Java class

You have now built a Domino session factory that will take care of basically creating and destroying the code. For the client example you will create a simple executable class that will use this factory and reuse an existing session adequately.

Do this by performing the following steps:

Right click the com.ibm.itso.sg247004.DominoSessionPool package and select New → Class.
Name this class ClientPoolTester. Be sure you select the checkbox that creates the main() method stub. Implement the Runnable interface as shown in Figure 6-20.

Figure 6-20: Creating the ClientPoolTester class

The ClientPoolTester class should open. Insert the following import statements:

    import org.apache.commons.pool.*;    import org.apache.commons.pool.impl.*;    import lotus.domino.*;

Add the following class variables to the class:

    public ObjectPool pool; // The pool that will manage our sessions    public static String mode = "pooled"; //Can be pooled or not pooled    public static long totalTime = 0; // This will keep the timer

Modify the default constructor to the following code:
```
    public ClientPoolTester() {       super();       PoolableObjectFactory factory = new DominoSessionFactory();       pool = new StackObjectPool(factory, 5);    } 
```
As you can see, you are creating a factory based on your previously created class and then you are creating an ObjectPool that will stack 5 Domino Sessions.

Modify the run() method to contain the following code:

    public void run() {       Session mySession = null;       try {          long timer = System.currentTimeMillis();          if (mode.equals("pooled")) {             // The session is borrowed from the pool             mySession = (Session) pool.borrowObject();          } else {             // A new session is created from scratch             mySession =                NotesFactory.createSession(                   "<servername>", "<username>", "<password>");          }          // Now we will print some session information          System.out.println("Domino Server: " + mySession.getServerName());          Database db = mySession.getDatabase(                          mySession.getServerName(), "names.nsf");          View view=db.getView("People");          // We will full text search the People view and print results          System.out.println("Found "+view.FTSearch(                   "FIELD LastName contains Admin")+" number of persons                   with an Admin Lastname...");          if (mode.equals("pooled")) {             // Now we will return the connection to the pool             pool.returnObject(mySession);          } else {             // Here we are recycling the session             mySession.recycle();          }          System.out.println("Running thread took: "                    + (System.currentTimeMillis() - timer)                    + " millisecs\n");          // Keeping the timer on every run...          totalTime += System.currentTimeMillis() - timer;       } catch (NotesException e) {          Exception ex = e;          System.err.println(e.getClass().getName() + ": " + e.text);          ex.printStackTrace();       } catch (Exception e) {          System.err.println(e);          e.printStackTrace();       }    }

As you can see, this run() method basically can run in two modes using pooled or non-pooled requests. If the mode equals pooled, the class will borrow a Domino Session from the pool and connect it to the names.nsf database and perform a full text index on the People view.

If the mode equals non pooled, it will create a session and after performing the same tasks will recycle the session.

Important:

You should create a Full Text Index for the names.nsf database, if there isn't one already, to run this example.

Also note that the totalTime variable is incremented by the execution of each run() method.

Have the ClientPoolTester class implement the interface runnable so that you can start several threads of this class and simulate a sample serialized access load into the pool.

Modify the main() method to the following code:

    public static void main(String[] args) {       try {          ClientPoolTester t = new ClientPoolTester();          // We will create 5 threads of this class          Thread nt = new Thread((Runnable) t);          Thread nt2 = new Thread((Runnable) t);          Thread nt3 = new Thread((Runnable) t);          Thread nt4 = new Thread((Runnable) t);          Thread nt5 = new Thread((Runnable) t);          // Now we will start each thread and put each thread to sleep          // this will help stabilize the pool.          nt.start();          nt.sleep(400);          // This sleep emulates work and stabilizes pool for access          nt2.start();          nt2.sleep(100); //This sleep emulates work          nt3.start();          nt3.sleep(100); //This sleep emulates work          nt4.start();          nt4.sleep(100); //This sleep emulates work          nt5.start();          nt5.sleep(100); //This sleep emulates work          // Finally wait for the thread to die          nt.join();          nt2.join();          nt3.join();          nt4.join();          nt5.join();          // Now we will close the pool and the session inside          t.pool.close();          // Print the total time to do the job.          System.out.println("************************");          System.out.println(" TOTAL TIME: " + totalTime);          System.out.println("************************");       } catch (Exception e) {          System.err.println(e);          e.printStackTrace();       }    }

The main() method basically creates five threads and starts each one of them. Every thread will start the run() method, and finally, the total time it takes to perform the five tasks is printed.

This approach to the Domino Session pool is extremely basic. There are other important considerations, not covered by this example, that should be included in an enterprise implementation. Among these considerations are:

Managing the DIIOP time out.

Domino Sessions should be pinged frequently to avoid timing out of the session and loosing the reference. In addition, you should recycle the session after some time to avoid possible memory leaks.
User management.

The credentials used to authenticate to the Domino server are fixed, depending on each portlet use case. You could group different types of sessions based on user profiles.
Pooling other objects, like Domino Views.

The Domino Session can be an expensive object to instantiate, so the pool will help make your portlet application perform better. There also are other objects that can be expensive to instantiate, like the View object, so you might consider pooling this object as well.
Handling of orphan sessions.
How the pool can grow in a controlled manner.
Other standard pool management characteristics. Consult the Jakarta Commons pool documentation for more information.

Analysis of the two approaches

In the lab, We ran the client in an Ethernet 100mbps network with the pool and with the create-destroy approach.

Note

This isn't a statistically valid analysis since we ran only 10 tests, and the testing environment wasn't a dedicated one. However, it does serve to illustrate, anecdotally, the fact that pools improve the performance of your application.

The results of the pooled approach are shown in Figure 6-21.

click to expand
Figure 6-21: Results from the pooled approach

The results of running the same client without using the pool are shown in Figure 6-22.

click to expand
Figure 6-22: Results from the non-pooled approach

We ran the test 10 times, and recorded the results shown in Table 6-2.

Table 6-2: Performance between pooled and non-pooled approaches
Run	Pooled approach (msecs)	Non-pooled approach (msecs)
Test 1	1172	5288
Test 2	1262	5298
Test 3	1302	5318
Test 4	1833	5356
Test 5	1232	5347
Test 6	1234	5368
Test 7	1241	5347
Test 8	1222	5307
Test 9	1202	5306
Test 10	1272	5317
AVERAGE TIME	1297	5325

The performance improvements were impressive in our tests: we had a 411% improvement when using the pooled approach. The test results are presented in Figure 6-23.

click to expand
Figure 6-23: Performance comparison- Pooled and non-pooled

< Day Day Up >