I went through this same issue in my application, and realized that rollbacks throw off the whole scheme. This proposal doesn't account for rollbacks: how would they work? If only the outermost "transaction" would truly perform a rollback, then what would an inner one do?
Consider this scenario: 1. begin() 2. do_db_work() 3. begin() 4. do_db_work() 5. rollback() 6. do_db_work() 7. end() What does line 5 do? What does line 6 do? What does line 7 do? I decided for my own work that magic nested transactions are a bad idea. To properly handle errors and rollback the database, you need to know where the edges of the transaction really are. Fully-supported nested transactions may be a good thing (I've never used them, so I don't know). But pretending that you have nested transactions when you don't is just waving your hands over some very important issues. --Ned. http://nedbatchelder.com -----Original Message----- From: Eli Burke [mailto:[EMAIL PROTECTED] Sent: Friday, April 01, 2005 12:33 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] idea: sqlite3_begin() and sqlite3_end() ? >That's a good question. It would save all the wrapper writers some >time. I don't think the library is the place to put thread safe >code for several reasons: > >Some of us don't use threads and don't need thread >safe code. > >I prefer modular code with as little mixing of function >as possible. It makes it easier for me to reuse code in >other projects. (For example: Don't put GUI messagebox >code to report errors into sqlite. I might want to use it in >an mp3 player, which doesn't have a GUI.) > >Since it's very operating system dependent it would >be difficult for Dr. Hipp to test. He doesn't have a copy of every >operating system and every version at his office. He probably >doesn't know how to write thread safe code on every OS either. > > > I don't think the discussion of adding sqlite_begin/end/rollback should get bogged down with whether or not it should support threads. It's an idea that stands on its own merit. Actually, come to think of it, each thread *should* have it's own DB handle, and each DB handle can use transactions independently of the others (IMMEDIATE/DEFERRED/ EXCLUSIVE notwithstanding). So really it's a non-issue. I shouldn't have mentioned it in the first place :-) -Eli
