On Thu, 24 Feb 2005 21:24:07 +0100, MvMarkus <[email protected]> wrote:
> Hi Ivo,
>
> It's about time that you join this discussion!
>
> The point that you mention at the end of your text is particulary
> interesting: How (if) can Empresa create a record lock which, according to
> the docs also locks the open indices, if different processes do not
> communicate with each other?
>
> My guess is that there is probably no such mechanism in Empresa, but instead
> the "record locking mechanism" in the docs refers to nothing else but an
> exclusive write access of the OS to the address (space) of the record on the
> disk.
>
> (Alternatively, is it possible that dbIIIs have an internal
> "record-is-updated-right-now-flag-do-not-touch-it flag" similar to d.deleted
> ?)
I don't believe so. I've written the beginnings of an xBase manager
in Ruby, and saw nothing like that in the specs. All you ever wanted
to know about xBase can be found here:
<A HREF ="http://www.pgts.com.au/download/public/xbase.htm (or by doing a google">http://www.pgts.com.au/download/public/xbase.htm (or by doing a google</A>
search for 'Bacchman xBase'
> Whatever it is, this does not help with finding a solution to the problem
> that I described in my previous post about preventing the database (or
> index) to change in the time between the assignment of the new database
> values and the beginning of the database transaction.
>
> Therefore, if the new value depends on other values in the database (or the
> number/position of records in the database or index), the only remaining
> available tool is MvLOCKFILE. But to get it to work properly, all functions
> that could possibly write to that table and index must explicitely request
> it. Or not? A horrible idea, in my opionion, and a clear contradition to the
> recommandations in the docs!
It seems to me that Brian has already found the solution. Sadly, it's
not a convenient one since it requires that the table be closed and
that your entire operation (open/update/close) be wrapped by the
MvLOCKFILE tags.
> "It would be nonsense to reinvent the wheel and integrate the functionality
> directly into Empresa."
>
> I don't think that this is really the objective here. The whole discussion
> aims to
Personally, I'd love for Empressa to be "smarter" about what's going
on between processes, but I'm not expecting that to happen.
> 1.) Finding a secure way to protect tables from index corruptions during
> concurrent updates or adds. We all know that this is an existing problem in
> Miva, especially as the error handling provides warnings of such a
> corruption, but no integrated protections/recovery. When you have a
> duplicate error in the index, the incorrect value is still (first) written
> into the table. This is, in my opionion, a real design flaw in the dbIIIs or
> Empresa.
>
> 2.) Gaining better understanding over the different locking mechanisms,
> their functionality, applications, reliablity, performance costs, to be
> ultimately able to write scripts that are robust and efficient, even under
> heavy load.
>
> Of course we can always say "forget dbIIIs, I use a SQL db". But that's no
> fun.
That may be the way they go, but I'd like to keep access to dbf also.
--
Bill Guindon (aka aGorilla)