Simon,
Consider a bank which takes an audit every day at
close-of-business. This might be declared to be 5pm. However,
accounts are continued to be debited and credited all night, due to
interest being added, ATM transactions, etc.. Nevertheless, the audit
needs to see a snapshot as of 5pm.
Of course, no bank would be using SQLite for this purpose, because a
bank would be using a server/client DBMS. But you get the idea.
I don't believe this can be any close to a real-world scenario,
client/server architecture set aside.
Being able to issue and process a BEGIN SHARED IMMEDIATE for the read
lock be in place at exactly 5pm, without ever missing a transaction
performed from elsewhere at 04:59:59:999.99 nor including a transaction
commited at 05:00:00:0.001 seems to be an impossible task in practice.
One may find it uncomfortable to ignore the delay between BEGIN is
issued and when the next SELECT gets the lock set, but in fact you
would never know either the delay between your program issuing BEGIN
SHARED IMMEDIATE and the precise moment the lock is actually setup,
unless under a low-load real-time OS providing explicit garantees on
various exec times. And even there, I'm not that sure.
From my remote/naive viewpoint, this is a misuse of a RDBMS relying on
DIY. When you want/need to be sure what you are going to read is ante
<some timestamp> the only serious way is to include a precise enough
timestamp in data rows and limit the select using it.
Indeed if you would want to do that and if you need to be just on time,
you would rather use rock-solid:
select <columns> from <table> ... where timestamp between
<begin-period> and <end-period>
I still fail to imagine a useful use case for such feature.
As Igor shown, A==B and A!=B are indiscernable.
Further in the thread the argument of "symetry" between BEGIN SHARED
IMMEDIATE and BEGIN IMMEDIATE is only a surface view, because the arrow
of time is one-way. A real symetry would be a BEGIN IMMEDIATE TO BE
COMMITED BEFORE <timestamp> but that clearly doesn't make any sense.
JcD
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
