On 3 Jul 2014, at 6:11pm, Srikanth Bemineni <bemineni.srika...@gmail.com> wrote: > > As per Igor > BEGIN IMMEDIATE should get a write lock on the table 1 when first select > call is initiated > > 10:00.234 Thread 1 BEGIN > 10:00.235 Thread 1 select * from <table1> > 10:00.234 Thread 1 select * from <table x> > 10:00.456 Thread 1 delete from <table1> > 10:00.500 Thread 1 COMMIT > > Igor > > 1. If there is no second thread , then the above transaction works fine. > Here also I am doing the select operation first . So the same thread can > update a read lock to write lock ? > > 2. Will BEGIN IMMEDIATE get a write lock on the table for the first select > statement as per the thread sequence above.
You're referring to 'read lock' and 'write lock' but it's easier to think of there just being a lock. BEGIN IMMEDIATE gets a lock right there at the BEGIN IMMEDIATE command. It doesn't have to wait for anything later. Now nothing else can happen to the database until the COMMIT/ROLLBACK. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
