Too Many Open Files (was Re: The CLOSE command)

[Kenneth Brody]

Quoting Fairlight (Fri, 17 Feb 2006 22:33:40 -0500):
[... filePro's automagical locking of unprotected lookups ...]
> What happens if it's "too late" and someone already grabbed that record?
> The fact that it protects a record semi-automagically only makes this
> case more ambiguous--at least to me.

As I said in my previous post, it simply narrows the window of
opportunity for shooting oneself in the foot.

User A looks up to record 1 w/o a lock.
User B looks up to record 1 w/o a lock, and gets it.
User A modifies a field in the lookup, and filePro automagically locks
    the record.
User B modifies a field in the lookup, and filePro attempts to lock the
    record.  Since it's already locked by A, it waits.
User A releases the lock (write/getnext/close/etc).
User B now continues, and locks the record.

Note, however, that B continues using the original version of the
record, not the version as modified by A.

However, if user B doesn't do the lookup within the window between A
doing the lookup and subsequently locking it, then the problem has
been avoided this time around.

[... "close happy" ...]
> I agree.  But you -should- close it at the first atomic moment you're
> done with the -batch- of lookups then, if you have further processing
> to do--not just let them hang open until you're done.

I guess it depends on the definition of "this batch of lookups".  If
you are in output processing, and you are done with the file for this
particular record, are you done with "this batch" if the next record
in the output will perform another lookup to this file?

On the other hand, you may be in *clerk, performing a lookup to the
inventory file when the user enters an invoice item.  Once the info
in the inventory file is read/updated, you may not need that file
again for some time.  And, even if it will be only a few seconds later,
the fact that you are limited by the human typist, the overhead of
closing and reopening the file may be insignificant.

[...]

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com