CommonGround Softworks Inc.


			


November 19, 1998 - Osmosis Technical Note #2

Subject: Write-Locking

Write-locking (sometime the term "Record Locking" is used) is a specialized function of Helix® that prevents more than one user from modifying a record at any one time. In normal client-server operation, an enterable record is 'locked' whenever a user attempts to modify one or more fields. This means the record will be placed into a 'read-only' status as regards other users who attempt to view/modify this same record. A record is 'unlocked' when the record is saved or the window is closed. Helix interface guidelines inform the user (via a beep and Why? alert) when a record is locked.

When a record is entered (stored) via AppleEvents (AEEA), Helix performs record locking. Unfortunately, there is no uniform user interface approach. Therefore, the Osmosis user needs to be able to identify when write-locking is occurring and how to create suitable Helix structures to deal with it.

AN OSMOSIS USER WILL MOST LIKELY EXPERIENCE RECORD LOCKING WHEN...

More than one Osmosis script (with different Process Names) attempt to write to the same record; and

The number of script accesses is very high (>1/second).

WHERE OSMOSIS WILL REPORT...

An Osmosis HTML error, "A record locking problem has occurred"; or

An Osmosis HTML error or Osmosis log entry, "An AppleEvent error has occurred, HAE_GetRow (Download Failed)".

What Helix is reporting is the AEEA call could not be completed because the requested record was locked, and therefore unavailable.

In what situations are we most likely to find the same record being written to? The use of a 'Global' relation, where there are many fields, but only one record. Using a global design, we continually update one or more fields, but it is always the same record. Helix locks records, not fields. Here's an example:

An AEEA store request is made to a view. The view has one inert field which is posted on entry to a global relation on a True=True link. The global record is locked during the entry, then unlocked as soon as the entry is completed. The actual time the record is locked varies, but is generally less than a fraction of a second.

Now suppose we have 10 AEEA store requests, from different scripts with different Process Names within a 1 second period. The likelihood of a record lock increases due to sheer volume and the finite amount of time necessary to process each entry.

TO ADDRESS THIS PROBLEM, WE CAN USE A VARIETY OF APPROACHES...

Create a global relation with more than one record. Designate each record with a unique key. Each view, through which the AEEA store request is made, uses a post with a different key. This works well when the specific Osmosis script also uses a Process Name.

Create multiple global relations, each with one record. Each view, through which the AEEA store request is made, posts to a different global relation. This approach is suggested when you output views from a global relation.

Use the same Process Name for all Osmosis scripts that post data to a global relation. Osmosis will process scripts with the same Process Name synchronously. This is suggested for sites that do not anticipate a high volume of traffic.


 

webmaster@CommonGrnd.com