Depending on the application logic (i.e if iterations or loops exist), I
think it's a good idea to regularly flush the buffers from memory to disk.
This will improve concurrency and (according to Bruce Tobacks comments)
should reduce the time needed to finally unlock the file.

As far as I know the are two ways to flush the buffers from memory. FUNLOCK
(and probably FCLOSE) but also FCONTROL with the appropriate option.

Aprox 2 Drachmas worth ...

Costas Anastassiades,
Intracom SA
Athens-Greece

----------
From:   toback2[SMTP:[log in to unmask]]
Sent:   Τρίτη, 2 Δεκεμβρίου 1997 11:25 μμ
To:     [log in to unmask]
Subject:        Re: To Lock or Not To Lock?

Yes, FUNLOCK posts buffers to the file. That's necessary since every
user's view of the file has to be consistent after the UNLOCK, but not
necessarily while the file is locked. The need to post buffers means that
every page of the file that's in memory has to be checked to see if it's
dirty. If a lot of the file is in memory, that can take a while.

For large files, one alternative is to lock a separate, small file that
exists entirely for the purpose of providing a semaphore. That works very
well for memory-mapped files, but I'm not sure if FLOCK/FUNLOCK also
interact with transaction management in some way. If so, you'd lose the
benefit of that management if you use a separate semaphore file.

-- Bruce


--------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my friends -
Phoenix AZ 85028                   | It gives a lovely light.
btoback AT optc.com                |     -- Edna St. Vincent Millay
Unsolicited mail to [log in to unmask] will be inspected for a
fee of US$250. Mailing to said address constitutes agreement to
pay, including collection costs.