Most online search applications need to be designed and developed in a way that supports multiple concurrent users.

For the purpose of this section, a "search transaction" is defined as a complete search, from the point of accepting the search criteria, to the point of delivering the search results.

This search transaction must perform the calls to SSA-NAME3 as well as the database I/O to retrieve candidate records (or else invoke a database stored procedure to retrieve the candidates). It is highly recommended that the part of the process that issues the database I/O (or the entire application) executes wholly on the server where the database instance is running, or performance degradation can be expected.

With SSA-NAME3 V2, the memory required by SSA-NAME3 to service the search transaction’s calls is managed (acquired and released) by the SSA-NAME3 Callable Routine (rather than by the search transaction itself). When a new transaction calls the SSA-NAME3 DLL, Shared Library or Load Module, SSA-NAME3 will acquire the memory needed to service the various function calls from the transaction’s address space. If a transaction calls the SSA-NAME3 server instead, SSA-NAME3 will acquire the memory from the SSA-NAME3 server address space. The memory acquired is used to load the Population Rules needed to service this request and also as a work area.

SSA-NAME3 assumes a transaction is new if either it does not recognize the session-id passed on the call, or a session-id of -1 is passed. In both cases, it assigns a new session-id and passes it back to the transaction. For optimum performance, that is to save SSA-NAME3 from re-initializing the memory, the transaction should use the returned session id in all function calls for the life of that transaction (typically one

ssan3_get_keys

call and multiple

ssan3_match

calls).

There is also a performance benefit if the Population rules can be maintained in memory across transaction boundaries. This way, even a "new" transaction can use the previously loaded Population rules, even though it will need a new work-area.

To do this requires use of a multi-threaded process. This can either be developed by the user, or optionally, the SSA-NAME3 server can be used instead of the Shared Library or DLL.

If using the SSA-NAME3 server all that is required is a global storage area that is not attached to any particular transaction, but is accessible by all transactions and has the characteristic of an entry being able to be locked for update. Such a storage area would normally be in memory; however theoretically it could be in a file or database table. This global area would store a pool of session-ids and socket handle pairs. A transaction would search this session-pool for an available session, mark it as "in-use" and make all of its SSA-NAME3 calls using that session-id and socket handle. When it is finished, it would mark the entry as "available".

When using the SSA-NAME3 server, a transaction will communicate directly with it through TCP/IP. To open a TCP/IP socket and connect to the server requires the use of a specific SSA-NAME3 function call,

ssan3_connect

. There is a corresponding ssan3_disconnect call. The SSA-NAME3 server ensures that the Population rules are kept in memory over transaction boundaries.

When using the SSA-NAME3 server it is imperative that a separate socket

ssan3_connect

call be allocated for each thread. That is, different threads must not share the same socket.

If not using the SSA-NAME3 server, a multi-threaded application can be developed by the user to perform a similar function. Such a process would be responsible for both managing the pool of sessionids, calling the

SSA-NAME3 DLL

and for starting the search transaction threads that will use those sessions. This process could initialize a number of SSA-NAME3 sessions when it is started, and manage those session ids itself, or leave it to the threads to initiate and manage.

In either case, a new transaction would use an already open (but not "in-use") SSA-NAME3 session, and not incur the overhead of the open or the close.

In this design, an important point to remember is that session-ids and socket-handles cannot be used by more than one active transaction/thread at the same time. Otherwise, the search results will be unpredictable.