> 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 From
> docs: After a BEGIN IMMEDIATE, no other database connectio
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
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 "
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 sys
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 locki
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.srik
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
On 3 Jul 2014, at 6:11pm, Srikanth Bemineni 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
> 10:00.234 Thread 1 select * from
> 10:00.456 Thread 1 delete from
Hi,
For some reason I was not getting any mails from the groups. At last Mike
Owens was a able to resolve the issue. I did used to get the digest mails
which contained the conversation with respect to this thread. Just to
rephrase from what ever I understood till now
As per Igor
BEGIN IMMEDIATE s
On 7/2/2014 2:06 PM, Clemens Ladisch wrote:
Igor Tandetnik wrote:
On 7/2/2014 3:04 AM, Clemens Ladisch wrote:
If all else fails, one could try and simulate BEGIN IMMEDIATE by running
a dummy modifying statement right after BEGIN - e.g.
delete from table1 where 0;
Would this be atomic?
It w
On 2 Jul 2014, at 7:06pm, Clemens Ladisch wrote:
> There is no documented way to start a transaction with a write lock,
> thus I see no mechanism that could reliably prevent deadlocks.
Right. Sharing your cache means you're sharing your transactions and sharing
your locks. If you need to loc
Igor Tandetnik wrote:
> On 7/2/2014 3:04 AM, Clemens Ladisch wrote:
>>> If all else fails, one could try and simulate BEGIN IMMEDIATE by running
>>> a dummy modifying statement right after BEGIN - e.g.
>>>
>>> delete from table1 where 0;
>>
>> Would this be atomic?
>
> It would be part of the same
On 7/2/2014 3:04 AM, Clemens Ladisch wrote:
If all else fails, one could try and simulate BEGIN IMMEDIATE by running
a dummy modifying statement right after BEGIN - e.g.
delete from table1 where 0;
Would this be atomic?
It would be part of the same transaction, wouldn't it? The idea is to
m
Igor Tandetnik wrote:
> On 7/1/2014 4:55 PM, Clemens Ladisch wrote:
>> To prevent deadlocks, transactions that will modify the database should
>> be started with BEGIN IMMEDIATE. (This kind of lock is not available
>> in shared cache mode.)
>
> Are you sure?
Sorry, I meant "locking", not "lock".
> On 1 Jul 2014, at 10:36pm, Igor Tandetnik wrote:
>
> On 7/1/2014 5:20 PM, Igor Tandetnik wrote:
>> On 7/1/2014 4:55 PM, Clemens Ladisch wrote:
>>> To prevent deadlocks, transactions that will modify the database should
>>> be started with BEGIN IMMEDIATE. (This kind of lock is not available
>
On 7/1/2014 5:20 PM, Igor Tandetnik wrote:
On 7/1/2014 4:55 PM, Clemens Ladisch wrote:
To prevent deadlocks, transactions that will modify the database should
be started with BEGIN IMMEDIATE. (This kind of lock is not available
in shared cache mode.)
Are you sure? Nothing in the documentation
On 7/1/2014 4:55 PM, Clemens Ladisch wrote:
To prevent deadlocks, transactions that will modify the database should
be started with BEGIN IMMEDIATE. (This kind of lock is not available
in shared cache mode.)
Are you sure? Nothing in the documentation appears to suggest that. But
I must admit
On 7/1/2014 4:40 PM, Srikanth Bemineni wrote:
10:00.234 Thread 1 BEGIN
10:00.235 Thread 1 select * from
10:00.234 Thread 1 select * from
10:00.456 Thread 1 delete from
10:00.456 Thread 2 BEGIN
10:00.456 Thread 2 select * from
10:00.906 Thread 2 select * from
10:01.156 Thread 2 delete from
Srikanth Bemineni wrote:
> Lately we are seeing a dead lock kind of state while deleting records
> from a table.
>
> All threads open their own shared connection to the database.
Why are you using shared cache mode?
To prevent deadlocks, transactions that will modify the database should
be starte
Hi,
We are using the sqlite 3.7.14.1 code in our application. Lately we are
seeing a dead lock kind of state while deleting records from a table. The
deletion is done two different threads and acting upon the same table.
Sqlite is configured in WAL mode. All threads open their own shared
connect
20 matches
Mail list logo
