/   Site Map  /   About Us  /  General Products  /  MV Products  /  Outsourcing   / Home page   /

Persistent and Non-Persistent Connections

PixieWeb

Non-Persistent Sessions Communication on the WWW is, by default, stateless (non-persistent). Each client request to a server is treated as a unique and one-time event. From the client side it is taken for granted that your browser appears to be the only client making requests of a particular server. In fact, the server may be processing many other requests in the time it takes you to read a web page or complete a form on a page you have received. When you send your next request to the same server, the server responds without knowing if the request is from you or a new visitor. Client requests are received by the server, the server sends the response and then the interaction is effectively forgotten by the server (non-persistent). This results in limitations in trying to perform on-line transactions where the next step is dependent on what was done in a previous step. This is especially true when using PixieWeb field-by-field techniques, and this continuity (persistence) is required with the complex and interactive nature of our state-of-the-art applications. If you are running a PixieWeb batch-form read-only application then normal non-persistency is fine. The user submits a request for data, the server logs-on, grabs the data and passes it back to the user (client), and the server logs-off and the connection is broken. Another request starts the process off again from the beginning. Persistency during the data grabbing process only is all that is required. Persistent Sessions In the persistent mode “sessions” are needed to control the continuity of processing complex transactions. The web-server automatically provides the "session cookie" to establish persistence, so cookies are no concern of anyone programming with PixieWeb. The persistent connection from the web server to PICK is an object, stored in the session object. Persistence in a PixieWeb application is the often preferred mode because: (1) It provides for Field-by-field, on-the-fly, data validation to be applied, and, (2) Efficient one-page applications can be developed where only changed data is repainted on the screen. Persistence in a PixieWeb application is the default mode because: (1) PICKBasic is a persistent environment by default, and, (2) The application is run from a persistent PixieWeb framework ("XDLTemplate.htm" working with "XDLPixie.asp"). Note, that this persistence creates a one-to-one relationship between clients and licenced ports. (More later on allowing a greater number of users than licenced ports in a persistent mode.) Each web browser using a persistent connection establishes it's own Telnet connection with the MV database, but this does not necessarily require the browser to be assigned a separate MV database license. Connection pooling is offered by some MV databases so that more than one Telnet connection can be established using the same license. Contact your Pixieweb VAR, Master Distributor or PixieWare for more information. Customising or Managing Non-persistent Connections However, developers using PixieWeb field-by-field techniques may require the ability to create their own form of non-persistent connections. These are actually customised persistent sessions that are broken and made repeatedly at the back-end application server. They are needed for example if more clients are needing to access the application than available licenced ports, or in a Linux & Apache combination where there may be difficulties in processing normal persistent sessions. If you have to develop your own non-persistence model it is up to the developer to decide how it’s done. There is nothing built into PixieWeb to handle this non-standard model, but example code is supplied to guide the developer. With this customised non-persistent mode, the Session-ID becomes the persistent point of reference and so it is used as the Item-ID for PICK files (expanded upon later) which remember the state between connections. Session details and the "Session-ID" obtained from IIS. A Session-ID, as the name implies, is another way for a server to keep track of interactions with different users. Session-ID's differ from Cookies in that they normally only exist for the duration of a transaction or "session" with a server. A server may reset or clear a Session-ID issued to a client when a transaction is complete or if the client is no longer making requests of the server after a certain time-out period. Another difference with Session-ID's is that they are usually part of the web page sent to the client browser rather than being written to file on the client machine. This means that they may be included in hidden input fields as part of a page. A typical custom-written non-persistency scheme behaves as follows. In all cases, "sessions" as in work in progress for a user, is saved to a file with some kind of session-id as identifier. On re-connection, the session-id from IIS or the Client is used to find that item to continue from where processing was interrupted. The session-id may be pre-stored in a hidden field on the web page. Basically a Session-ID, which contains some encrypted data about the user's login-id, etc., is generated and stored in the client's memory. This is stored as a **memory-only** cookie on the client, and is also the key to a SESSION file stored on the back-end (say in D3). Once the user closes his window, the memory-only cookie vanishes, in keeping with the 'disconnect' concept familiar to Telnet users. The session-id is absolutely unique per user per connection, so it is quite possible to allow the same user to log-in multiple times and not 'walk ontop' of a concurrent session from another window from the same-user/same-client. Stale sessions are automatically purged after a pre-set period of time has elapsed. The back-end SESSION record contains information about the user's: account number, name, time/date connected, last known focus (typically last program accessed and last command initiated by the client), as well as last error message collected from the back-end program. The results from the user's perspective appear to be a seamless GUI connection even though every event fired from the client PC is actually a "log-in, do something, log off" sequence. One of the nice side-effects of this model is the ability to 'log off' web users remotely simply by deleting the session record on the back-end. It will lock out the client on the next navigation attempt. Whenever something significant happens in the application it needs to be logged. A single sub-routine may be built to log events to the SESSION file with a key of the session-id. Not every event needs to be logged. Only those related to navigation and messaging. This means that if something occurs that sends a message to a client, log it in the SESSION file under 'last message'. If the user navigates through a menu tree, you DON'T have to update the session file unless they: (a) drills down to a sub-level in the tree or (b) makes a selection or (c) pops up a level. A simple 'mouseover' may be ignored. So NAVIGATION events (true user-initiated 'clicked' focus events, server-forced focus events), and messages (fatal and information-only) are the key things to be logged. Note, that not every CRT/PRINT statement is required to be logged. Having a single 'bottleneck'/API for this kind of activity is useful (for obvious reasons such as enhancing it to talk to web interfaces), whereas in-line PRINT/INPUT statements of the classic old-style approach might require a lot of re-development to be done. In the situation where there is a centralized input/output routine, this routine is made responsible for all CRT/PRINT statements and logging. An example ASP script processing the session information can be viewed here: http://script.  Pixieware connects you easier, faster and more reliably to MultiValue data.

Email: sales@pixieware.com

/   Site Map  /   About Us  /  General Products  /  MV Products  /  Outsourcing   / Home page   /