Quoth Lynton Grice <lynton.gr...@logosworld.com>, on 2010-09-30 10:11:54 +0200: > Bottomline: We have one writer and multiple readers per queue....fine. > > Then I scratch my head and wonder why SQLite is not the PERFECT persistence > layer for building an awesome "file based queue" on? It is lightening fast > by default, and also has the same "locking issues" described above. We are > talking milliseconds anyway....between writes.... > > Bottomline: Is there any reason why anyone would think someone like me > coding a solid message queue using SQLite is a bad idea?
I don't think it would be a bad idea per se, but I'm not sure it would gain you much over other approaches. It would certainly be simple! If you're going for high performance, I would be a little wary of rollback journal activity multiplying the number of synchronized writes. WAL mode would help with that, but it would increase the underlying complexity WRT filesystem and shared memory accesses. ---> Drake Wilson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
