According to Geoff Hutchison:
> > If the problem is file locking preventing simultaneous digging & searching
> > (which is still to come if I understand correctly), wouldn't the same
> > problem affect the docdb? I'm no expert on this, but shouldn't htsearch
>
> The issue isn't file locking. AFAIK, the Berkeley code can do all that
> behind the scenes.
>
> > use this new docheaddb the same way it uses the docdb, or how it used to
> > use the index db in 3.1? I don't understand the need to use a static
> > variable.
>
> There isn't a *need*, but it seemed like a static variable could cut the
> overhead on constantly initializing and opening a Database object.
>
> The index and docdb variables are usually opened infrequently. For
> example, htdig opens them *once*. Since the DocumentRef class is called
> all over the place, it would be nice if it didn't have to constantly open
> and close the db.
>
> Does that make any sense?
Yes, I follow you. But, DocHead doesn't seem to be accessed anywhere
in code that isn't already accessing docdb, which makes sense, as it's
currently a field in docdb records. So, it seems to me that if you
handle the new dochead db in much the same way as the existing docdb,
that shouldn't introduce too much overhead or complications. Currently,
docdb is opened once in each of the programs, so why not open dochead db
at the same time, and leave it open until processing is done? Maybe even
write it as a sub-class of DocumentDB?
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
