Submitted by Syd Nicholson on Fri, 09/28/2012 - 00:00
Forums
IceBreak

Hi Niels,

I have a question regarding session time out.

Putting a record on to a screen and allowing the user to change the data, presents (of course) a multiuser issue. I am putting together a system whereby the first user to get the data "locks" the record. I can't use a real record lock, this would break the system.

This lock is based on the sessionID, and I can enquire on file SES00 to find out if the session still exists. The application uses a short session timeout (30 minutes) and a "heartbeat transaction" from the browser to keep the session alive. If the user goes away (switches off, goes to another page, etc) their session times out.

So far so good -- but what would be really handy -- is knowing when the session times out. Is there an exit point I can use to catch session time out. A program at such an exit point, could automatically remove the "lock" information from the appropriate DB files.

Best regards
Syd

Niels Liisberg

Sat, 09/29/2012 - 00:00

Permalink

Hi Syd;

This is a great feature you are describing. We will put it on our "TO DO" list.

We already have some exit points in IceBreak which can be configured in the webconfig.xml file in each server root. We can make new entry like this:

<session cleanupExit="mylib/mypgm" />

Your exit program will receive the session-ID (which is a timestamp) as the first parameter.

How does that sound?

Best regards,
Niels

Hi Syd;

The "Webconfig.xml" is rather new and is not documented yet – But the idea is that when you deploy your server – you also deploy the webconfig.xml so options like your exit points also hit the destination server along with .html .js and what ever…

I'll keep you posted...

To day – one of the few features already implemented in webconfig.xml is the upload path and security - ( from the "programmers guide": )

Uploading files to a IceBreak server

Programming:
In this tutorial we will create a simple IceBreak program which uploads files - either to the IFS or to an internal large object (ILOB). Basically this program is just a simple HTML form. The magic however is in the combination of the form encoding type set to multipart/form-data and the special input fields of type "file".

Configure the allowed destination:
When you upload files they will be placed with a temporary name in the /tmp folder on the IFS - from here it is your responsibility to move them into your designated folder. You can, however restrict/allow the client to upload into one or more dedicated folders. You simply place a configuration file in Your server root path called webConfig.xml

The configuration file has a upload element which again can contain a map of valid directories an the corresponding alias as the client refer to it. Finally You can give a generic folder path for any invalid upload filenames. This is indicated by an * as the alias name. By default that would be the /tmp folder on the IFS.

The webConfig.xml file is hidden from the client. It is only available in the physical path, not in the virtual counterpart.

The webConfig.xml contains (among other stuff) the following:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<upload>

  <map alias="frameworks" path="frameworks" />

  <map alias="upload" path="/www/anyplace/docs" />

  <map alias="*" path="/tmp" />

 </upload></configuration>

 The configuration above says:
· Any uploaded files designated to virtual folder "frameworks" will be placed in the sub-folder

"framework" in the server root path.

Any uploaded files designated to virtual folder "upload" will be placed in the absolute path "/www/ anyplace/docs"
The final "*" alias is a "catch all" - so all other virtual folder references will be placed into the "/tmp" folder

Best regards,
Niels Liisberg 

Hi Niels,

I have another question for you:

If a user has a record on the browser display, then opens another tab and works on the same record. -- Then they are both in the same session and cannot "lock" each other out of changes, unless of course one uses a native DB record lock.

Is the server port number, combined with the server session sufficient to distinguish between the two browser pages?

In other words, can the server port number be used to distinguish between browser "tabs/windows" in the same session, and is it consistent enough to be used in "record lock" information placed in a DB file?

Best regards,
Syd

Hi Syd;

It is the underlying session that keep track of the record locks. So if you need an extra session for the browser – then you can, as you suggest, connect with another port. This however requires that you have an extra server configuration available for that extra port.

Another – more straight forward solution - is to use journal and commitment control. Since your session is jobstable, then you can lock (even read records) in to your session and keep record lock on multiple records / rows.

Best regards,
Niels Liisberg