Subject | Re: [ib-support] Serialization? |
---|---|
Author | Martijn Tonies |
Post date | 2002-07-05T15:47:57Z |
Hi,
In this case - why don't issue a statement:
start transaction
UPDATE HOST
SET FREE = 'N'
WHERE ...
AND FREE = 'Y'
commit
If this update doesn't update rows or results in a dead-lock, some other
thread has updated the row.
Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com
Upscene Productions
http://www.upscene.com
"This is an object-oriented system.
If we change anything, the users object."
In this case - why don't issue a statement:
start transaction
UPDATE HOST
SET FREE = 'N'
WHERE ...
AND FREE = 'Y'
commit
If this update doesn't update rows or results in a dead-lock, some other
thread has updated the row.
Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com
Upscene Productions
http://www.upscene.com
"This is an object-oriented system.
If we change anything, the users object."
> Friday, July 05, 2002, you wrote:
>
> MT> There are many ways to solve such a problem. One way to make sure
> MT> that only ONE thread is downloading from a single host is simply
> MT> putting a constraint on the host name and continueing to the next
> MT> host if you cannot insert into the table - that way you know that
> MT> some other thread is already searching that host.
>
> Oh, sorry, I guess I've been misunderstood.
> When a thread gets a document, it parses it and extracts all the links
> it contains. Then, it inserts those links in the database for further
> retrieval.
> So, the fact that a host is inserted in the table doesn't mean there
> is a thread retrieving documents from it! It only means that one (or
> more) URL is based on that host.
> That's the source of my problem: an URL can be used for retrieval if
> its HOST is "marked" as "free". But if two threads try to get a URL in
> the same time, they could update the HOST row to mark it as "no more
> free" whitout any problem! That's because they could both find it free
> with the first query.
> Maybe if I perform a SELECT FOR UPDATE I can solve the problem?
> SELECT whatever_I_need
> FROM HOST