diff options
Diffstat (limited to 'contrib/userlock/README.user_locks')
| -rw-r--r-- | contrib/userlock/README.user_locks | 56 |
1 files changed, 0 insertions, 56 deletions
diff --git a/contrib/userlock/README.user_locks b/contrib/userlock/README.user_locks deleted file mode 100644 index 5e61d4eea0..0000000000 --- a/contrib/userlock/README.user_locks +++ /dev/null @@ -1,56 +0,0 @@ -User locks, by Massimo Dal Zotto <dz@cs.unitn.it> -Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it> - -This software is distributed under the GNU General Public License -either version 2, or (at your option) any later version. - - -This loadable module provides support for user-level long-term cooperative -locks. For example one can write: - - select some_fields, user_write_lock_oid(oid) from table where id='key'; - -Now if the returned user_write_lock_oid field is 1 you have acquired an -user lock on the oid of the selected tuple and can now do some long operation -on it, like let the data being edited by the user. -If it is 0 it means that the lock has been already acquired by some other -process and you should not use that item until the other has finished. -Note that in this case the query returns 0 immediately without waiting on -the lock. This is good if the lock is held for long time. -After you have finished your work on that item you can do: - - update table set some_fields where id='key'; - select user_write_unlock_oid(oid) from table where id='key'; - -You can also ignore the failure and go ahead but this could produce conflicts -or inconsistent data in your application. User locks require a cooperative -behavior between users. User locks don't interfere with the normal locks -used by Postgres for transaction processing. - -This could also be done by setting a flag in the record itself but in -this case you have the overhead of the updates to the records and there -could be some locks not released if the backend or the application crashes -before resetting the lock flag. -It could also be done with a begin/end block but in this case the entire -table would be locked by Postgres and it is not acceptable to do this for -a long period because other transactions would block completely. - -The generic user locks use two values, group and id, to identify a lock. -Each of these are 32-bit integers. - -The oid user lock functions, which take only an OID as argument, store the -OID as "id" with a group equal to 0. - -The meaning of group and id is defined by the application. The user -lock code just takes two numbers and tells you if the corresponding -entity has been successfully locked. What this means is up to you. - -My suggestion is that you use the group to identify an area of your -application and the id to identify an object in this area. - -In all cases, user locks are local to individual databases within an -installation. - -Note also that a process can acquire more than one lock on the same entity -and it must release the lock the corresponding number of times. This can -be done by calling the unlock function until it returns 0. |