Re: [sqlite] Reader locks writer in truncate mode?

[veeresh kumar]

I should have been more specific. There are lots of threads, Identifying which 
thread is having the lock at any given time would have been helpful.

Also need clarification on this one - A reader thread should still be able to 
read data from database until writer thread in transaction tries to commit the 
data?




On Thursday, 13 March 2014 4:43 PM, Simon Slavin  wrote:
 

On 13 Mar 2014, at 11:12pm, veeresh kumar  wrote:

> Thanks a lot for the response. Is there any way to identify which 
> thread/process is actually blocking the reader thread or vise versa?

Only in that it's the one that didn't get the error message.  The one that's in 
the middle of a SQLite API call.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Reader locks writer in truncate mode?

[Simon Slavin]

On 13 Mar 2014, at 11:12pm, veeresh kumar  wrote:

> Thanks a lot for the response. Is there any way to identify which 
> thread/process is actually blocking the reader thread or vise versa?

Only in that it's the one that didn't get the error message.  The one that's in 
the middle of a SQLite API call.

Simon.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Reader locks writer in truncate mode?

[veeresh kumar]

Thanks a lot for the response. Is there any way to identify which 
thread/process is actually blocking the reader thread or vise versa?
 
-Original Message-
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] 
On
Behalf Of Simon Slavin
Sent: Thursday, March 13, 2014 2:30 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Reader locks writer in truncate mode?
 
 
On 13 Mar 2014, at 9:27pm, Igor Tandetnik  wrote:
 
> On 3/13/2014 5:24 PM, veeresh kumar wrote:
>> In a multi-threaded application, say a reader
thread has read 100 records from the table and reading is still in progress
before which writer thread writes data and tries to commit. Its causing
database lock.Is this expected?
> 
> Assuming the two threads use two distinct database
connections - yes, this is expected.
 
Don't forget that by default SQLite does /no/ retries if
there is an access clash.  You can change
this by setting a timeout:
 
<https://sqlite.org/c3ref/busy_timeout.html>
 
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

Re: [sqlite] Reader locks writer in truncate mode?

[Igor Tandetnik]

On 3/13/2014 5:24 PM, veeresh kumar wrote:

In a multi-threaded application, say a reader thread has read 100 records from 
the table and reading is still in progress before which writer thread writes 
data and tries to commit. Its causing database lock.Is this expected?


Assuming the two threads use two distinct database connections - yes, 
this is expected.

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Reader locks writer in truncate mode?

[veeresh kumar]

In a multi-threaded application, say a reader thread has read 100 records from 
the table and reading is still in progress before which writer thread writes 
data and tries to commit. Its causing database lock.Is this expected? 


Note : journal_mode is set as truncate
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Reader locks writer in truncate mode?

[Simon Slavin]

On 13 Mar 2014, at 9:27pm, Igor Tandetnik  wrote:

> On 3/13/2014 5:24 PM, veeresh kumar wrote:
>> In a multi-threaded application, say a reader thread has read 100 records 
>> from the table and reading is still in progress before which writer thread 
>> writes data and tries to commit. Its causing database lock.Is this expected?
> 
> Assuming the two threads use two distinct database connections - yes, this is 
> expected.

Don't forget that by default SQLite does /no/ retries if there is an access 
clash.  You can change this by setting a timeout:



Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users