Bert,
I may be confused by the multi-thread question on this mailing list. A
user was asking whether a single handle to SQLite could be used by two
threads. The answer being 'no' of course. At the least one handler per
thread/process would always be needed.
I like the idea of a transaction queue.
To start with I would like to see whether concurrent access is possible
without a queue. Providing the schema is not changed and no concurrent
access is attempted on the same tuple.
Should be simple to test.
But there may be reasons why this will never work, or be incredibly
dangerous.
For instance, if a 'write' changes the key structure or position in the
file of other tuples. In this case it will never work.
If any user knows whether this is a waist of time, please let me know :)
Thanks for the ideas so far.
Ben
Bert Verhees wrote:
Op maandag 13 juni 2005 17:44, schreef Ben Clewett:
F.W.A. van Leeuwen,
I am only using SQLite. I would never consider accessing the database
file directly. Madness that way lies... :)
Bert,
I agree that SQLite should not be used multi-thread. I think there was
a lot of discussion about multi-threads using the same SQLite handle. A
big no-no :)
I am interested in mult-processor access. Which SQLite does handle.
But using a single global lock. Which I keep hitting.
I am trying to find out two things:
- If row locking was used: Is it possible for two or more processes
read/write different rows in the same table at the same time without
conflict.
You want a multithreaded access to the database. Or multiprocess, which in
fact from perspective of the database is the same thing.
I cannot say of that is possible., But there are soulutions, when you write a
engine which handles the calls to the db, and has a queue-mechanism. In many
cases a singlethreaded access will do. But I can imagine that there are cases
where this will not do. Maybe someone else can answer to that
Regards
Bert Verhees
- If this is the case, how can row-locking best be enforced. Whilst
maintaining integrity, speed and ease of use.
This simple addition to SQLite would make a real difference to the
abilities and target applications to which SQLite can be put to.
Ben
F.W.A. van Leeuwen wrote:
I personally don't think this is a big issue for SQLite.
A database file will typically only be accessed by the programs designed
for it (i.e., they know the format).
If another (closed source) program accesses the database file - out of
your control - it will be a problem anyway.
Typically the only ones that are out of your control are programs like
SQLiteExplorer, but they could be modified as well.
Best regards,
Frank.
