On Thu, Jan 11, 2001 at 03:43:39PM +0800, Lincoln Yeoh wrote:
> Hi,
>
> Has anyone any input to offer on adding an arbitrary locking feature?
>
> Where
> GETLOCK "string" will lock on "string", the lock being only released at the
> end of a transaction.
>
> While the lock is held, other processes trying to do GETLOCK "string" will
> block until the lock is released.
>
> This feature can allow applications to better serialize things. For
> example: inserting unique records. Cooperating applications could just do
> something like:
>
> GETLOCK "mytable.key2=1234";
> SELECT count(*) from mytable where key2=1234 for update;
> if count==0, insert the stuff.
> elsif count==1 update the stuff instead
> else something is wrong!
>
> The lock will thus only affect applications interested in mytable where
> key2=1234
We do something like this with listen/notify pairs. To syncronize
two clients, we have them each listen for the other's token string,
send a notify, and then block on select(), checking for incoming
notifications. When they get the notification, they send a notify back
to the other side to un-block it.
If anything, it would be nice if there were a way to make a LISTEN
block the connection on a specific event tag, which is essentially what
we are doing in our interface library.
--
Adam Haberlach |A cat spends her life conflicted between a
adam@newsnipple.com |deep, passionate, and profound desire for
http://www.newsnipple.com |fish and an equally deep, passionate, and
'88 EX500 |profound desire to avoid getting wet.