Hello gang. I recently did some work with another system which supported transactions (a journaling file system) then came back to SQLite and saw it with a different eye. In my programming for SQLite so far either each database change has been handled by a different PHP process which opened a different connection, or a long-running application does sqlite3_open() once when it starts up and _close() when it quite. But the programming style I've been using recently does the equivalent of allowing any number of concurrent "BEGIN"s and handing back a handle for each one. You can execute any number of commands (SELECT or write) for each BEGIN, and then close the transaction with an "END" or "ROLLBACK".
SQLite, of course, does not hand back a handle for each "BEGIN". A BEGIN inside a transaction is, correctly, an error. But I find myself wanting to handle my transactions more ... erm ... modularly. So if I was to change my programming style accordingly ... (A) What should I be using as transaction handles ? Do I do a different sqlite3_open() for each transaction or is there some other level ? (B) Which journaling mode supports this use best ? Any other advice about PRAGMAs ? (C) In an application where any number of writing transactions can be running at one time, what is going to be my expected 'blocking' operation ? Would it be a second transaction executing a database change _step() ? Or does it happen when I close a transaction ? (D) Do I expect to see a big time penalty for changing to this style of working ? Thanks for any discussion, help or advice. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
