record_locking record_locking uses a variation on the AJAX/Web 2.0 method of asynchronous Javascript Web page.
Download

record_locking Ranking & Summary

record_locking Tags

Ajax JavaScript Asynchronous asynchronous Javascript Web 2.0 methods record lock

record_locking Description

record_locking uses a variation on the AJAX/Web 2.0 method of asynchronous Javascript Web page. record_locking uses a variation on the AJAX/Web 2.0 method of asynchronous Javascript Web page updating to maintain the record lock on the server. Opening a record for editing launches a background Javascript process in the user's browser that checks the status of the record lock every 10 seconds.Each status check updates the lock timestamp, confirming that the user is still connected and actively editing the record. Locks are normally released when the user saves the record or navigates to a different screen. If the user fails to properly close/release the record (abandons the record or his browser crashes), locks go stale if not updated for 5 minutes. The next status request or attempt to lock the record will delete or overwrite any stale lock.This record locking solution was originally created to allow the membership database a private social organization to be converted to an on-line LAMP application. LAMP originally referred to Linux, Apache, MySQL, PHP, but now is commonly used to refer to web-served applications regardless of the database and scripting language used. The membership database uses PostgreSQL for its database, but this solution is relatively independent of the actual database used. The example code may require the replacement of a few php/PostgreSQL API calls with the equivalent php/MySQL calls to work with MySQL.There has been a lot of effort to create enterprise grade multiuser LAMP applications, since this approach promises to solve a lot of major problems - such as platform independence, eliminating the overhead of maintaining software on the user's workstation, etc.However, one of the dirty secrets of LAMP apps is that the record locking provided by the database server only functions for the duration of the transaction - which in the case of a browser based UI is only during a single html request/event. There isn't any established means of maintaining a record lock over multiple html "interactions" with the user - ie: during the time while the user has the record in his browser window for editing. A true multi-user app requires "application level" record locking to ensure that only one user can change a record at a time. Enabling members to change (parts of) their own records creates a non-zero possibility of race conflicts with the office manager or other authorized admins attempting to change the same record.In a race conflict, the last user to write to a record overwrites any earlier changes by other users.I think I've worked out a solution to application level record locking in web-served programs. The solution uses a variation on the Ajax/web 2.0 method of asynchronous javascript webpage updating to maintain the record lock on the server. Opening a record for editing launches a background javascript process in the user's browser that checks the status of the record lock every 10 seconds.Each status check updates the lock timestamp, confirming that the user is still connected and actively editing the record. Locks are normally released when the user saves the record or navigates to a different screen. If the user fails to properly close/release the record - abandons the record or his browser crashes - locks go stale if not updated for 5 minutes. The next status request or attempt to lock the record will delete or overwrite any stale lock.Saving a record requires a current lock owned by the user. This protects against obsolete cached data being resubmitted to the database. The user must remain in effectively continuous contact with the database in order to successfully change a record - emulating the behavior of a conventional "closely linked" application.The user's background javascript process requests a special php file that manages the lock directory and generates a minimal html response back to the calling javascript process with the current lock status. The javascript process parses this returned html message and updates the lock status window. In order to avoid hammering the hard disk with lock traffic, the special php file and lock directory are loaded into a ramdrive mounted as the lock/ directory tree.Figuring out the Ajax portion of the solution was a major problem. All I could find on the web was a single Dr. Dobbs article from 2006 with a partial source code example. I couldn't find any working examples of this or any other viable web-served record locking system. I did find a significant amount of discussion about the need for application level locking, and the flaws in various other approaches. I couldn't get the suggested method in the article to work, but I was able to build on the basic concept to work out a solution that seems to work pretty well.Installation:These files and instructions assume a Red Hat/CentOS system architecture. Unpack the tar.gz file into a directory.Copy the following directories to the document root of the application - or add the contents to existing directories with similar purposes. The contents of most of the files could be inserted into appropriate existing files, if their functions and timing are sufficiently compatible. Only the lock_rec.php file needs to remain a separate file to function properly. /include/js/lock/templatesThese directories should belong to the web server user. The header and footer files in the template directory should be included into the application specific webpages for editing and saving the database records. The /init.d directory contains a shell script fragment that should be inserted at the top of the system V init script used to start, stop, and restart the apache web server (httpd). The file also contains instructions on where to insert the fragment. The file into which the fragment must be inserted is typcially located at: /etc/rc.d/init.d/httpdThis init script code takes care of creating two ramdrives, mounting them at the appropriate points in the server's filesystem, and copying the lock_rec.php file into the /lock ramdrive, whenever the apache web server is started/restarted. The ramdrive for the lock files should be mounted at the /lock directory that branches from the application's document root directory. The php code needs to be able to read and write to the lock directory. The sessions ramdrive should mount at /var/www/html. Php must be able to read and write to this directory.

record_locking Related Software