Object Persistence |
Active Web |
 |
|
Object Persistence |
Active Web |
|
Server-side scripts can create objects to hold data but most of these objects only live for the life of the script and are disposed of when the script is delivered to the browser.
In some cases you may want to create data that persists for more than the life of one script. Active Web provides a number of different ways to persistent storage most of which are based on files.
You could use a database to store the data but this is an application issue and not considered as part of the scope of this document.
The first point to make about persistence is that there are two types of persistence: Servlet persistence and Eternal persistence. Servlet persistence is data that persists until the server is stopped, when it is discarded. This data is held in memory. Eternal persistence is data that will remain while the servlet is stopped and be available again when the servlet is restarted. This data is held in files within the web application.
In addition to these types of persistence there are also two types of data: Constant data and Variable data. Constant data is always the same and can be read at any time by the script but can not be changed. Variable data can be changed as well as being read.
When you use persistent data you need to be aware of the problem of simultaneous access. This is when two script pages access the data at the same time. If the data is Constant then there is no problem, but if the data is variable and both scripts are changing the data at the same time then the result will be unpredictable. This situation can easily occur even in the simplest of web pages if multiple users access the same page at the same time.
The solution to the simultaneous access problem is to use locking. This is available in the Locking Prototype in some of the persistent storage objects but not in all. To use locking the script must call the lock() function before accessing the data and call the unlock() function after the data has been updated. The lock does not prevent access to the data but instead acts like a gate to get the access to the object. When a script calls lock() it joins a group of scripts waiting for object access and it will not return from the lock() function until it has been given permission to access the object. The unlock() function allows another script in the group access to the object. If a script locks an object but does not unlock it the unlock will happen automatically at the end of the script execution.
The project object (see The 'project' Object) is a built in script object and is always available to all scripts. There is one project object for each directory under the web application root. All scripts under the same 'project' directory have access to the same project object.
When the servlet is started it creates a new project object for each project directory, reads the project initialization parameters for the project (from the web.xml file) and populates the project object with those parameters.
The following xml shows how an example project can be defined with parameters in the servlet’s web.xml file.
<servlet>
..
<init-param>
<param-name>project_xtutorials</param-name>
<param-value>
projParamNameOne = projParamValueOne;
projParamNameTwo = projParamValueTwo
</param-value>
</init-param>
..
</servlet>
Because the servlet creates new project objects each time it is started this means that the project object provides Servlet persistence and not Eternal persistence.
A script can put any properties into the project object. The properties will then persist until they are removed or the servlet is stopped. The project object allows the script to set the lifetime of any of its properties. When this lifetime has expired the property is discarded.
example:
project.myData = "a string of info";
project.expire(project.myData, 10);
In this example the property "myData" has been set in the project object and given a lifetime of 10 minutes. After 10 minutes the "myData" property will be discarded.
The project object supports the locking feature.
 |
projects and their parameters may be manipulated via the Active Web Console Config/Projects (see Projects), this removes the requirement to directly edit the web.xml file. |
The session object (see The ‘session’ Object) can be used for object persistence on a per session basis in the following manner:
createSession();
request.jsession.setAttribute(‘name’,’value’);
Whilst the session exists, the session attribute ‘name’ will be available to any scripts, which may access it:
var a = request.jsession.getAttribute(‘name’);
In affect this gives a third form of persistence – ‘session’, allowing objects to be shared between various scripts in the same session. Although obviously, this does not provide for sharing of data between users, as each would have a unique session. Session based persistence may have greater longevity than servlet persistence if the container technology provides the ability to maintain session information through servlet restarts (this is a servlet container feature so you would need to consult the containers documentation).
The servlet may be used to provide servlet object persistence via its context object (see The ‘context’ Object) , in a manner similar to the session object. The major difference from session persistence is that the persisted objects will be available to all sessions, as follows:
servlet.context.setAttribute(‘name’,value’);
Then in any script where the set value is required:
var a = servlet.context.getAttribute(‘name’);
An ObjectFile is an object created in a script using the 'new' operator. The ObjectFile is created with a file name that identifies the ObjectFile. When the server creates the ObjectFile it first checks to see if it already has the ObjectFile in its memory. If the ObjectFile is in memory then the script is given a reference to the ObjectFile. If the ObjectFile is not in memory then the file specified is read (if it exists) and a new ObjectFile is created and given the properties defined in the file.
ObjectFiles are identified by their file name and there is only one ObjectFile of that name in the server. All scripts using the ObjectFile with the same name share the same ObjectFile.
A script can put properties into an ObjectFile. The properties will persist until they are removed or the server is stopped.
The properties held by an ObjectFile can be saved to its file by using the write() function. But this will only save primitive objects (Strings, Numbers & Booleans). Objects such as Java objects, Date objects, Library objects etc can still be put in an ObjectFile but will not be saved to the file. The full object model structure of the ObjectFile is saved including any arrays.
When the server is stopped all ObjectFiles and their properties are discarded. When the server is restarted the first reference to an ObjectFile will recreate the ObjectFile and restore any properties saved in its file. This means that ObjectFiles provide a mixture of Server persistence and Eternal persistence.
ObjectFiles support the locking facility.
The FileWriter and FileReader objects are created in a script using the 'new' operator with a file name that identifies the file. These objects allow the script to write and read character data to and from files. The objects do not persist in server memory and are mentioned here because they allow you to persist data by saving it in a file. These objects do not impose any structure on the data other than it must be character data.
The FileWriter and FileReader objects do not support the locking facility and thus file writing should be treated with care to avoid simultaneous access. You could implement your own locking scheme using the project object lock.
A Properties object is created in a script using the 'new' operator with a file name that identifies the file. This object reads properties from its file. The properties are one per line with a name and a value separated by an equals sign.
After the Properties object has been created calling the read() function causes it to load all the properties in the file into the Properties object. A script can put any properties into a Properties object and can save the properties back into the file by using the write() function. This will only save the string value of the properties and it only saves enumerable properties at the top level.
Properties objects do not persist in server memory and so only provide Eternal persistence.
Properties objects do not support the locking facility.
A Library object is created in a script using the 'new' operator with a file name that identifies the library file. When the server creates the Library object it first checks to see if it already has the Library object in its memory. If the Library object is in memory then the script is given a reference to the Library object. If the Library object is not in memory then the file specified is read and a new Library object is created.
Library objects are identified by their file name and there is only one Library object of that name in the server. All scripts using the Library object with the same name share the same Library object.
When a Library object is created it is given a 'name' property that is the name of the library converted to a file path starting from the servlet web application root. A script can put any property into a Library object. The properties will persist until they are removed or the server is stopped.
When the server is stopped all Library objects and their properties are discarded. When the server is restarted the first reference to a Library object will recreate the Library object but will not restore any properties previously held by the Library object. This means that Library objects only provide Server persistence.
Library objects do not support the locking facility.
 |
Library objects are deprecated in Active Web – Developers should use the Fragment object instead. |
Topic ID: 150079