your sunglasses won't stop my gaze
On Mon, Jul 7, 2014 at 4:21 PM, mm.w <0xcafef...@gmail.com> wrote: > 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
