On Fri, May 07, 2004 at 09:22:59AM +0100, Paul Smith wrote: > Given that (IMHO) most concurrency problems seem to be centred around a > single application with multiple threads, might it not be possible for that > application to 'register' with SQLite in order to implement table locks.
> Similarly for the tables. The application could do all the hard work in > this case. That sounds ok technically, but if I were the author and primary maintainer of SQLite, the first question I'd ask myself is, "Do I really want to have to sift through a bunch of bogus bug reports about SQLite corrupting data because the programmer implemented his table locking callbacks incorrectly?" I don't know how hard or easy it would be to do those callbacks right. If it's easy, that's probably fine. If it's NOT easy, I would worry about the above, and while worse for users who need the feature, for the maintainers, it might be better to not include that locking callback feature at all, or at least not to publicize it. Of course the MVCC designs batted around on this list would be better, but also, presumably, a lot more work. For that, Doug Currie's suggestion to "integrate the shadow paging ideas with BTree management" sounds like the best idea so far: http://www.mail-archive.com/[EMAIL PROTECTED]/msg01982.html -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
