Re: Locking & concurrency - best practices - Mailing list pgsql-general

From Erik Jones
Subject Re: Locking & concurrency - best practices
Date
Msg-id A5CE8F78-0F69-46EE-B1E4-C194CE7C2223@myemma.com
Whole thread Raw
In response to Re: Locking & concurrency - best practices  (andy <andy@squeakycode.net>)
Responses Re: Locking & concurrency - best practices
List pgsql-general
On Jan 14, 2008, at 3:54 PM, andy wrote:

> In our program we wrote the locking into the program, and created a
> modulelock table like:
>
> create table moduelock(
>   userid int,
>   module int,
>   primary key (userid, module)
> )
>
> The program then locks things before it uses them... but we also
> have pretty low contention for modules.
>
> A lock is:
> begin
> insert into modulelock...
> commit;
>
> if commit ok, then go ahead.  When we are done, delete from
> modulelock where ...

 From what I can tell, this kind of roll-your-own application level
locking system is exactly what advisory locks are for.  Search the
archives for the last couple of weeks as I remember someone posting
some really helpful functions to assist in using advisory locks.

Erik Jones

DBA | Emma®
erik@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com




pgsql-general by date:

Previous
From: andy
Date:
Subject: Re: Locking & concurrency - best practices
Next
From: "Adam Rich"
Date:
Subject: Re: Locking & concurrency - best practices