On Wed, 16 Sep 2009, Miguel Angel Marchuet wrote:
> Talking about readlocks is completely intentionally, because the
> server operates in serialize mode, the server is not multi thread.
Absolutely false information. You've said is was intentional so
you do not know that it's potentially very serious bug.
The fact that your server is not MT safe may strongly reduce the
server performance but does not help in dirty index reading in any
way because index scan operations are not atomic for the server.
Indexes are accessed in exactly the same number of operations as using
normal file IO. You disabled read locks what means that when you read
index other station can write to this index. Here is a simple scenario.
Each line is single atomic operation for your server:
client 1 locks index
client 1 reads page 1
client 1 reads page 2
client 1 modify page 1 (local operation)
client 1 modify page 2 (local operation)
client 2 reads page 1
client 1 write modified page 1
client 1 free modified page 2
client 2 reads page 2 which is subpage of page 1
but this page was just freed by client 1 and
contains dummy information (it can be even reused
by yet another client as part of different tag)
What will happen and what DBFCDX will do is
in practice random. If it detects that it's
wrong then it probably stop with internal
error. In some less critical situation you only
lost (skip) throw some records just inserted
or moved to other page by writing station
without any internal errors losing some
information or accessing some records more
then once if they were moved from the page
just scanned to the next one during
key balancing. But it doesn't matter for us.
Important is the fact that it's not safe.
client 1 unlock index
and this is end the discussion about safe access.
> for this reason RE_TURBO can be activated by default. Our application
> is running without GPF as you explain previously.
It does not make it safe what above example clearly shows so if you
believe in what you wrote then it's a problem only for you and your
customers. Anyhow you can try to calculate the risk and what is the
chance to exploit the problem. It depends on few things but if you
know how to calculate it then you should find that the transport
layer is unimportant and does not change anything. So dirty read
in REDBFCDX is unsafe in the same way as using local file IO or
some networks protocols like SMB with classic file server because
it does not reduce the number of atomic operations in single index
access, i.e. for SKIP, SEEK, UPDATED.
> REDBFCDX is only the beginning, as i explain some months ago, all dbf
> based RDDS at xharbour will work with this server or another as i explain
> yet to other developers at private mails, and too filesys subsystem.
> I'm finishing too, sessions and transactions, in similar way as is implemented
> at dBase IV
Transaction system it's not trivial job if you want to implement different
isolation levels. It needs some deeper modifications bound with indexing
code because it's necessary to introduce phantom index records visible
only for chosen stations when the old ones are still accessible for others.
I do not know what isolation level is implemented by dBase IV and looking
at your recent modifications I cannot even guess what is your goal.
So please forgive me but I will not comment what you plan to do as long
as I cannot see the whole code or at least know algorithms you are trying
to implement.
> I'm very interested in your observation about TURBO, but by the moment
> i don't have notice about any corruption or GPF using this type of server
> and of course not opening tables with external applications ;)
When sth can be clearly shown (see above algorithm) then there is no sense
to comment such sentences. It doesn't matter how often you will repeat it.
When I was studding informatics "It's working for me" was the last sentence
my teachers wanted to ever hear and was one of the shortest way to fail
the exam.
best regards,
Przemek
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
