Re: [sqlite] SQLite server/file-locking scenario

On 19 Nov 2013, at 6:40pm, Joshua Grauman wrote: > Under what conditions would an open() create a lock that would cause problems? If you did something with it that would interfere with the processes using SQLite's own API. For instance, if you chose options which involved

Re: [sqlite] SQLite server/file-locking scenario

Right. I'll go look at the source and confirm or just write it myself using POSIX open() which would be easy. I guess I was just asking what kind of locks you are talking about since I'm not familiar with file locking. In other words, if I did a POSIX open("filename", O_RDONLY); or even

Re: [sqlite] SQLite server/file-locking scenario

On 19 Nov 2013, at 5:05pm, Joshua Grauman wrote: > Ok, thanks again for the tips, I'll change the ROLLBACK to END. > > I'm assuming if I open the file read-only it shouldn't lock, right? I'm using > Qt, but I send it a read-only parameter which I assume translates into >

Re: [sqlite] SQLite server/file-locking scenario

Ok, thanks again for the tips, I'll change the ROLLBACK to END. I'm assuming if I open the file read-only it shouldn't lock, right? I'm using Qt, but I send it a read-only parameter which I assume translates into something like a POSIX open("filename", O_RDONLY); Josh On 19 Nov 2013, at

Re: [sqlite] SQLite server/file-locking scenario

On 19 Nov 2013, at 6:00am, Joshua Grauman wrote: > sqlite3_open_v2("sqlite3.database.filename"); > sqlite3_exec("BEGIN IMMEDIATE"); > file.open("sqlite3.database.filename"); > file.readAll(); > file.close(); > sqlite3_exec("ROLLBACK"); > sqlite3_close(); > > So does this

Re: [sqlite] SQLite server/file-locking scenario

Thanks again for the responses, very helpful. Taking into account that I can't just read the database file in my program without some sort of locking as was mentioned and explained clearly by multiple people (thank you!), I tried two different implementations to see which would perform

Re: [sqlite] SQLite server/file-locking scenario

I don't have time right at this minute to carefully read and respond to all the responses to me, but I have to at least at this point say a heartfelt *thank you* to all those who have responded to me. I'm blown away by how detailed and helpful and patient all the responses are. When I have

Re: [sqlite] SQLite server/file-locking scenario

This is gonna be a long one, but I added (hopefully) some humor to make it a bit better of a read. @OP Just so I'm clear, you're pushing SQL statements from clients to your server, but then pushing raw data from the server to the client? Myself, I'd never push a "Work In Progress" database, or a

Re: [sqlite] SQLite server/file-locking scenario

On 17 Nov 2013, at 6:17am, Joshua Grauman wrote: > Thanks so much for the reply. Sorry for the ignorance, but wouldn't only the > sectors (page cache) that are being written need to be cached? If Unix did that (which it doesn't in any File System I know of) then that

Re: [sqlite] SQLite server/file-locking scenario

On Sat, 16 Nov 2013 22:17:31 -0800 (PST), Joshua Grauman wrote: >Thanks so much for the reply. Sorry for the ignorance, but wouldn't only >the sectors (page cache) that are being written need to be cached? Database pages are updated in sqlites page cache, then, being

Re: [sqlite] SQLite server/file-locking scenario

Thanks so much for the reply. Sorry for the ignorance, but wouldn't only the sectors (page cache) that are being written need to be cached? And I was trying to read up on how sqlite does atomic writes, but doesn't the way sqlite handles atomic writes guarentee that the file is *always* in a

Re: [sqlite] SQLite server/file-locking scenario

Thanks so much for the reply. Sorry for the ignorance, but wouldn't only the sectors (page cache) that are being written need to be cached? And I was trying to read up on how sqlite does atomic writes, but doesn't the way sqlite handles atomic writes guarentee that the file is *always* in a

Re: [sqlite] SQLite server/file-locking scenario

On 16 Nov 2013, at 11:37pm, Joshua Grauman wrote: > Or conversely, that if sqlite has the file open to write, my program will > read a cached version (if reading and writing happen at the same time, I'm > fine with the reader getting a slightly stale version). But I'm not