Re: using database for queuing operations?
От | Jeff Amiel |
---|---|
Тема | Re: using database for queuing operations? |
Дата | |
Msg-id | 414F4094.5050504@istreamimaging.com обсуждение исходный текст |
Ответ на | Re: using database for queuing operations? (Mark Harrison <mh@pixar.com>) |
Ответы |
Re: using database for queuing operations?
|
Список | 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 >
В списке pgsql-general по дате отправления: