We do encounter locking problems on configuration changes ( currently it is a single DB file ) For Statistic write operation optimization we collect all data and write in a single transaction, we had to do this without any foreign key / trigger dependencies, which create some DB scheme problems (theoretically)
The problem with my suggestion is - while the DB files are attached ( for example on the web server when need to supply a mix of configuration + statistics ) there might be a locking problem, so I need to attach detach based on specific scenario, wouldn't that have some overhead. - If I wish to preserve logical correlation bewteen the DB files in need to keep the attachment all around which brings me back to the starting point. We also checked the option of external table usage, but I am not sure what is locking scheme for external tables. On Tue, Oct 11, 2011 at 12:02, Simon Slavin <slav...@bigfraud.org> wrote: > > On 11 Oct 2011, at 9:56am, Gal Waldman wrote: > > > I am looking for ideas/solutions for Concurrency in my application. > > I have web-server for user configuration, where configuration changes -> > > write operation is scarce, at the same time I have a single monitor > > application which collect information from multiple probes which does > lots > > of statistics write operations. > > There's nothing about the above description which suggests it would fail. > My only comment would be that the app which does the writing has two > possible strategies: > > (A) Collect data from all probes. Write it all in one go. > (B) Collect data from one probe, write that, move on to next probe. > > Whether each one one works for you depends on how much data is collected > during each pass, and on several other things. No way we can advise you on > it and you're probably better just guessing, writing one of them, and seeing > whether it fails. > > > I thought about separating to configuration / statistics DB but I > understand > > that while attach is in place both DB's would be locked. any other > > suggestions ? > > Just don't do your stats calculations (or anything else time-consuming) > while the database is locked. So don't start a transaction, do one INSERT, > then start doing calculations before you can finish the transactions. > > Do you have a problem you are asking us to help you solve ? Are you > actually getting errors because your apps are both trying to access the > database at the same time ? > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Waldman Gal Products Manager ------------------------------ Mobile +972 522 558885 Fax +972 3 6209277 Email ga...@tagvs.com Skype waldman_gal Site http://www.tagvs.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
