Table of Contents

Search

  1. Preface
  2. Introduction
  3. The Design Issues
  4. Standard Population Choices
  5. Parsing, Standardization and Cleaning
  6. Customer Identification Systems
  7. Fraud and Intelligence Systems
  8. Marketing Systems
  9. Simple Search
  10. Summary

Application and Database Design Guide

Application and Database Design Guide

SSA-NAME3 "Sessions"

SSA-NAME3 "Sessions"

SSA-NAME3 manages the resources it needs to satisfy API call requests in memory areas called "sessions". SSA-NAME3 looks after acquiring, managing and releasing these memory areas.
The establishment of a session goes through an initialization process. During this process, the specified Population Rules are loaded, and a work-area for SSA-NAME3’s use is allocated. This is work that should happen as infrequently as possible, and this is to some extent under the control of the application designer.
As such, it is important for performance that all of the function calls from the same transaction or process use the same session.
One copy of SSA-NAME3 can handle 1024 sessions. In some cases, a large number of concurrent users, a large number of inactive sessions, or a large number of calls that do not properly re-use sessions, could lead to SSA-NAME3 running out of sessions.
If it is truly a large number of real concurrent users, then another copy of SSA-NAME3 may need to be started/loaded.
Otherwise, SSA-NAME3 will do its best to reuse sessions intelligently. However, if all else fails the SSA-NAME3 instance may need to be unloaded/reloaded or the SSA-NAME3 server re-started.
If a large number of users are expected to be using SSA-NAME3 services, it is recommended that the application be designed as server process that manages a pool of available sessions for calling client applications. For more information, see the
Designing a Multi-User Search Server Process
section below.

0 COMMENTS

We’d like to hear from you!