Re: using database for queuing operations?

From: Jeff Amiel <jamiel(at)istreamimaging(dot)com>
To: Mark Harrison <mh(at)pixar(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: using database for queuing operations?
Date: 2004-09-20 20:41:56
Message-ID: 414F4094.5050504@istreamimaging.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Although....it wont really solve the race condition issue...
you can still have a point where 2 processes select the same
record...one gets the 'for update' lock on it and the other one just
waits for it...
Regardless of the 'state', once that lock releases, the second process
will grab it.
In my world I have a 'main' process that selects all the records that
currently meet the criteria I am interested and them 'parse' them out to
the sub-processes via unique id.

Dont know if this helps....
Jeff

Mark Harrison wrote:

> Jeff Amiel wrote:
>
>> Add a column to the nameq table designating the 'state' of the image.
>> Then your logic changes to "select * from nameq where serial =
>> (select min(serial) from nameq) and state="UNPROCESSED" (or whatever)
>> So you select for update, change the state, then process the
>> image....then delete.
>
>
> Thanks Jeff, I think that will work perfectly for me!
>
> Cheers,
> Mark
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Amiel 2004-09-20 20:45:22 Re: using database for queuing operations?
Previous Message Jaime Casanova 2004-09-20 20:41:51 unique constraints on foreign keys