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. -- Met vriendelijke groet Bert Verhees ROSA Software
