On 6 Feb 2011, at 6:07pm, David M. Cotter wrote: > here's what i'm trying to do > > my software has two music stores > it downloads an XML for each music store, both at the same time
Is there any need to do that ? All your threads are running on the same computer. That's no faster than just querying each store in turn, processing the next new record (if there is one) then moving to the next store. If you can do that, stop here. > it then parses the XML into SQLite > each song has about 7 to 10 bits of data (columns) > and there may be 40k songs. > i need to be able to add all 40k songs to the DB in a way that can be rolled > back if a parse error occurs or if the user hits the stop sign or if the user > quits during the parse phase (which takes about 30 seconds) > see? I don't see why you have a problem here. Each thread writes to the database, doing all the writing for one record in a single INSERT command. While that INSERT is happening, the other thread is blocked. So what ? It's all happening on a single computer anyway: the bottleneck in the amount of time taken is probably how long it takes to write to your hard disk rather than processing time. If this is acceptable, stop here. By the way, if at all possible, stop using threads and use processes instead. Perhaps run one process for all the writing to do with each store. > and the two stores operate independently, on different threads Have a third thread that actually does the writing. The two threads you already have just prepare the data and hand it over to the third thread, which is the only one which actually writes to the SQL database. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
