Re: [sqlite] threads and transactions

> i'm not sure at all it's practical to create an 80MB string with one giant > SQL statement in it to send all that data at once. 80MB string is not too bad after all (probably even less than 1% of the whole memory). So you better do it this way. BTW, it won't be one SQL statement, it will be

Re: [sqlite] threads and transactions

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

Re: [sqlite] threads and transactions

bummrz. 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 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

Re: [sqlite] threads and transactions

On 6 Feb 2011, at 5:42pm, David M. Cotter wrote: >> If you don't need this behaviour because you're confident you'll never get a >> clash, then you could accumulate your INSERTs in memory, then blast through >> them when you would previously have just done the COMMIT. > > > i will never have

Re: [sqlite] threads and transactions

> If you don't need this behaviour because you're confident you'll never get a > clash, then you could accumulate your INSERTs in memory, then blast through > them when you would previously have just done the COMMIT. i will never have a clash because i manage the primary keys myself. is there

Re: [sqlite] threads and transactions

David M. Cotter wrote: > i may not have been clear > > i want to begin transactions on different threads at once Why, if you don't mind me asking? Your hard drive has only one write head. What makes you feel that writing to the same file from multiple threads would be any

Re: [sqlite] threads and transactions

David M. Cotter wrote: >> In SQLite every write is in a transaction whether you declare one with BEGIN >> or not. If you don't declare a transaction, SQLite >> invisibly surrounds each individual INSERT or UPDATE with a BEGIN and >> COMMIT. > sure, that's fine. but if

Re: [sqlite] threads and transactions

On 6 Feb 2011, at 1:30am, David M. Cotter wrote: >> In SQLite every write is in a transaction whether you declare one with BEGIN >> or not. If you don't declare a transaction, SQLite invisibly surrounds each >> individual INSERT or UPDATE with a BEGIN and COMMIT. > sure, that's fine. but if

Re: [sqlite] threads and transactions

forgive my not understanding this but i'm trying to be extremely clear and i am not sure from your answer whether you have understood my question. > In SQLite every write is in a transaction whether you declare one with BEGIN > or not. If you don't declare a transaction, SQLite invisibly

Re: [sqlite] threads and transactions

On 5 Feb 2011, at 11:00pm, David M. Cotter wrote: > i may not have been clear > > i want to begin transactions on different threads at once > in each thread > begin a transaction > insert lots of data, this may take a long time > commit transaction Okay, here's some

Re: [sqlite] threads and transactions

i may not have been clear i want to begin transactions on different threads at once in each thread begin a transaction insert lots of data, this may take a long time commit transaction i understand that one commit will block the other but does inserting data during a

Re: [sqlite] threads and transactions

> i understand that one "commit" will block all other threads from doing a > "commit", "rollback" or any atomic transaction, until it's done, but are you > saying i can't even add data on another thread while one has an open > transaction? There can be several simultaneous read-only

Re: [sqlite] threads and transactions

> Transactions are per-connection and have nothing to do > with threads. If you want different transactions in each thread you > need to make one connection for each thread. But those transactions > won't be able to execute simultaneously. so if i open a separate connection on each thread then

Re: [sqlite] threads and transactions

> presuming this timeline is chronological, may i assume that step 4 is > committed first in the database? You mean as a third transaction? No. > and that steps 5 and 6 operate independently? No. > even when threads 1 and 2 open their individual transactions, i see only ONE > journal file >

[sqlite] threads and transactions

i'm sure this topic has been beaten to death but i just really want to make sure. i'm using ONE database, and one handle to it on all threads here's a theoretical timeline -- 1) thread 1 begin transaction do bunches of stuff 2) thread 2 begin transaction do bunches of stuff