RidgeStar
About
Locations
Manual
Preface
Introduction
Versions
Concepts
Construction
Usage
JavaNames
Passwords
Pop Ups
Printing
Responsive
Results List
Search Criteria
Sessions
Symbols
Topics
Operations
Questions
Features
Settings
Internals
Appendices
Reference
Service
Logon
RidgeStar

Manual: Usage-Sessions

Logonfindtranslate
Get Started |Calendar |Locations

Every online, real time, interactive SiteTerm presents a series of panels (HTML Forms) permitting one or more Users to perform functions with. Data integrity in the backend database is typically managed at the "Record Level", which means that two or more Users can be processing DIFFERENT records in the database tables without problems.

Multiple Instances or Multiple Tabs

However, processing problems can occur if two or more Browser Sessions are operating on the same data at the same time. This is particularly problematic when the same User logs onto the same site multiple times and starts to interact with the site from different "Instances" (more than a single window on the desktop) or from different "Tabs" within the same Browser.

Browsers commonly in use during 2007 (Mozilla FireFox or IE 7.0 are the most common examples) offer these Tab capabilities to make the User more productive. However, the implementation chosen does not permit the ServerTerm operating the Site to recognize that the User is actually operating more than one Tab. Essentially, input from ALL the Tabs on the desktop within the same Instance of the Browser appear to the Server as if it is all originating from the same Browser and same User (which, technically, it is).

As a result, input from one Tab within the Browser cannot be logically separated by the Server from activity that is occuring from a second or subsequent Tab. Taken to it's logical conclusion, this characteristic CAN be responsible for cross tab confusion (an Update against a database record in one Tab may actually update a Database record that has been loaded in a different Tab, producing erroneous data being stored in the database). NOT Good!!!!

RidgeStar Session Support

For those clients that operate an interactive site that may be susceptible to this operational issue, RidgeStar offers what it calls the Sessions Feature. Once properly configured, it provides an environment that permits the Browser User to indicate to the Server that input on a given Tab or Instance should be treated independent of input on another Tab or Instance.

This is implemented by allocating additional TCP/IP Ports that can be used to identify different HTTP Sessions between the User and the Server. While this isn't an ideal solution, it does permit the separation of input into distinct Sessions that operate completely independent of each other. Meaning, there is no potential for input from one Session to cross into another Session and cause database corruption issues.

Note: This does NOT eliminate the potential for confusion if there are two or more sessions editing the same database record at the same time (this is "Database" related, not "Session"related). It does, however, eliminate the potential for cross-tab confusion (each Session operates independently of the other).

How to determine if the Sessions Feature is active on your Site

When the Sessions Feature is active, most Sites will have a series of Symbols that appear in the logical Header of each page. They are normally listed at the top of the page to the right of the User's name and to the left of the Search and/or GoTo elements (if they are active).

Each Symbol indicates if the Session is:

  • idle Inactive, but available
  • receive Active as the Current session
  • transmit Active, but not the Current session

You can switch to another Session by clicking on the alternate Symbol in the Header area (move your mouse over the symbol and pause for a short hint about what clicking on the symbol would do).

HOWEVER, RidgeStar recommends a different operational process to simplify the operation, which can be summarized as:

  1. When you start your Browser, connect the first Tab to the basic site by entering it's URL value (e.g. http://www.)
  2. You'll see a series of Symbols (discussed above) if your Site can initiate additional sessions (look at the top of this panel for an example)
  3. If you'd like a second tab connected to the same site, move your mouse over the top of one of the Inactiveidle Symbols (if available) and click the middle button on the mouse. For some systems, this might be a "Wheel" you can click with or you should be able to click both the left and the right buttons to simulate it (all depending upon your Mouse and System).
  4. This requests that the Browser use the Hyperlink associated with the Symbol to start a new Tab. When/if successful, the new Session will be completely independent in operation from the first Session. You can tell which Tab is associated with which Session by looking for which Symbol shows as Activereceive
  5. If your Browser supports ICONs to represent the page you are viewing, you'll also see alternate Symbols associated with each Session in the Tabs themselves. For instance, Referees.bizGoing uses ball to identify the primary session and the alternate Sessions are marked with session2 or session3 to identify the second and third supported sessions.

Important: Sessions support relies upon the proper "propagation" by your Browser of the TCPIP Port number onto the hyperlinks in the Pages within the Session. IF you click to a Web address outside of the Site or click on a URI that does not properly reference the Port, you WILL return to the Primary Session. Watch for this happening by observing either the ICONs in the Tab or which Session Symbol is currently Active on the page you are looking at.

If this happens, you CAN resume the desired Session by simply clicking the desired Sessiontransmit Symbol in the header area.

Be very careful with how you use the Sessions Feature. While quite useful, if you get the Sessions crossed or mixed up:

Data integrity CAN be compromised if you are not careful!