Hello everybody,
I have the following situation:
1. a writer needs to continuously append some data in 1 or 2 tables, *
without* any possibility to be blocked.
2. one (or eventually more) reader needs to read the data for analysis.
Pt 1 is very important; therefore I use a "PRAGMA locking_mode = EXCLUSIVE"
in the writer.
Then of course the reader can NOT read anything.
As I understood until now, there is no standard way to have real concurrent
read/write in sqlite.
I understand that in normal database operations a read uncommitted is not
possible with sqlite (I am talking about different processes).
In my situation I (try to) use sqlite as a data storage format. During
writing there are only appends, no inserts (in the middle) or updates.
(after the writing, standard database operations are applicable). The reader
needs to poll and try to read new data from the file.
I hope that using some usage restrictions, this might be possible. Therefore
I tried to enable reading without locking.
So found the "SQLITE_ENABLE_LOCKING_STYLE" define which might allow (value
2) exactly this behavior; unfortunately it seems to be used only for Unix
files.
Is there a reason not to enable this behavior via a special pragma (only
together with read-only)? I prefer to have a run-time switch, to be able to
use the same code everywhere.
Otherwise I modified winLock function with this code (the second condition
is mine):
..............
if( pFile->locktype>=locktype ){
return SQLITE_OK;
}
// gc: always allow shared lock!
if(locktype==SHARED_LOCK){
pFile->locktype = SHARED_LOCK;
return SQLITE_OK;
}
I did not changed winUnlock, because it doesn't care if unlocking fails
(from shared lock). Of course this is not a full implementation, just a
quick change to test if it would work.
Then I tried in a loop with 2 programs to write / read in parallel and it
seems to work without problems. Can anyone advise if this has any chance to
work (or say it would definitely NOT work)?
As a short summary: would it be interesting for anyone to enable read-only
open with a special pragma to allow reading without locking (that means,
shared locks being a noop)?
PS. I also tried to use HDF5; it is faster, but I like the simplicity of
sqlite (and my data is not that complex to require hdf5).
Thanks for your attention,
Gabriel
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
