On Tue, Nov 16, 2010 at 10:29 AM, Ruslan Mullakhmetov < r.mullakhme...@tools4brokers.com> wrote:
> > as you see in _serialized_ mode "SQLite can be safely used by multiple > threads with no restriction". > > do i misunderstand something? > With serialized threading, SQLite is perfectly "safe" to use. But if you change a value (the last-insert-rowid in this case) then that change will appear in other threads. There is nothing "unsafe" about that - you just need to be aware that it happens. "Safe" does not mean "atomic". If nothing else, this entire discussion should make it abundantly clear that threads are a very dangerous construct and should be actively avoided in all software that strives to be robust and/or reliable. People rant and rail about the evils of "goto" or pointers, and to be fair, those constructs are easily misused. But threads are a far more insidious evil in that they are non-deterministic: the failures happen differently on each run, or perhaps not at all until the product goes into production. Understand this: Any programming language that is built around threads is inherently broken and should be avoided. (I will not name names - you know the languages I'm talking about.) And any operating system that depends upon threads for performance is equality busted and should also be shunned. "Threadsafe" is an oxymoron. Nothing is safe when threads are in play. There are merely differing levels of hazard. So the best solution to your problem, Ruslan, is to not use threads. Failing that, allocate a separate database connection for each thread. If you can't do that, then you are going to have concurrency issues to deal with, regardless of what libraries you use. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
