comply to my request or stop, sorry but truth must be told at some point.
On Mon, Jul 7, 2014 at 6:02 AM, Srikanth Bemineni < bemineni.srika...@gmail.com> wrote: > Hi, > > How can I find this in the statement ? > > Will BEGIN immediate get an exclusive lock.? or like Igor specified if I > call "Delete * from where 0" will it be able to get an immediate lock on > the table. > > Srikanth > > > > On Sun, Jul 6, 2014 at 9:21 PM, mm.w <0xcafef...@gmail.com> wrote: > > > what's the syscall set behind the scene might help, os? > > > > > > On Sun, Jul 6, 2014 at 6:04 PM, Srikanth Bemineni < > > bemineni.srika...@gmail.com> wrote: > > > > > Hi, > > > > > > Is it possible for any SQLLite developer to explain the locking > > mechanism > > > in case of the shared connections, specifically table level locking, > how > > I > > > can debug this and find out who is holding the lock. ? > > > > > > Srikanth Bemineni > > > > > > > > > > > > > > > On Thu, Jul 3, 2014 at 12:47 PM, Srikanth Bemineni < > > > bemineni.srika...@gmail.com> wrote: > > > > > > > Hi, > > > > > > > > But in shared cache mode. I assume this is going to be a table level > > > lock, > > > > instead of a lock on the whole database. This will really block other > > > > threads which are dealing with other tables. > > > > > > > > > > > > http://www.sqlite.org/sharedcache.html > > > > > > > > 2.1 Transaction Level Locking > > > > > > > > SQLite connections can open two kinds of transactions, read and write > > > > transactions. This is not done explicitly, a transaction is > implicitly > > a > > > > read-transaction until it first writes to a database table, at which > > > point > > > > it becomes a write-transaction. > > > > > > > > At most one connection to a single shared cache may open a write > > > > transaction at any one time. This may co-exist with any number of > read > > > > transactions. > > > > 2.2 Table Level Locking > > > > > > > > When two or more connections use a shared-cache, locks are used to > > > > serialize concurrent access attempts on a per-table basis. Tables > > support > > > > two types of locks, "read-locks" and "write-locks". Locks are granted > > to > > > > connections - at any one time, each database connection has either a > > > > read-lock, write-lock or no lock on each database table. > > > > > > > > At any one time, a single table may have any number of active > > read-locks > > > > or a single active write lock. To read data a table, a connection > must > > > > first obtain a read-lock. To write to a table, a connection must > > obtain a > > > > write-lock on that table. If a required table lock cannot be > obtained, > > > the > > > > query fails and SQLITE_LOCKED is returned to the caller. > > > > > > > > Once a connection obtains a table lock, it is not released until the > > > > current transaction (read or write) is concluded. > > > > > > > > > > > > As per the above documentation > > > > "Once a connection obtains a table lock, it is not released until the > > > > current transaction (read or write) is concluded." > > > > > > > > This means once the statement is finalized or the whole transaction > > > > is committed. Currently I am getting an error on table level locks > > > > > > > > Thread 1 SQLITE_LOCKED(6) Error <Table1> is locked > > > > Thread 2 SQLITE_LOCKED(6) Error database table is locked > > > > > > > > Srikanth Bemineni > > > > > > > > > > > > On Thu, Jul 3, 2014 at 12:35 PM, Simon Slavin <slav...@bigfraud.org> > > > > wrote: > > > > > > > >> > > > >> 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 > > > >> > > > > > > > > > > > _______________________________________________ > > > sqlite-users mailing list > > > sqlite-users@sqlite.org > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
