On Mon, 21 Jan 2019 18:12:25 -0500
Richard Damon wrote:
> Some operations can be order of microseconds if the data resides in
> cache,
Thank you, I hadn't considered that. I was thinking that seek times on
"spinning rust" -- which is the only economically feasible technology
for large
On 1/21/19 4:38 PM, James K. Lowden wrote:
> On Sun, 20 Jan 2019 17:01:25 -0700
> "Keith Medcalf" wrote:
>
>> SQLite3 however has latencies on the order of microseconds
> Is that really true? Are there machines for which SQLite's throughput
> can be measured in transactions per millisecond?
>
On Sun, 20 Jan 2019 21:51:19 +
wrote:
> > insert into t
> > select :pid, nrows, N
> > from (select 1 as N union select 2 union select 3) as cardinals
> > cross join (select :pid, count(*) as nrows from t) as how_many;
> >
> > By using a single SQL statement, you avoid a user-defined
> >
On Sun, 20 Jan 2019 17:01:25 -0700
"Keith Medcalf" wrote:
> SQLite3 however has latencies on the order of microseconds
Is that really true? Are there machines for which SQLite's throughput
can be measured in transactions per millisecond?
I think you're referring to the latency of the
On Mon, 21 Jan 2019 at 07:21, Keith Medcalf wrote:
> In DELETE or TRUNCATE (that is, all modes except WAL) a READ transaction
> in progress blocks a WRITE transaction and a WRITE transaction in progress
> blocks all other attempts to commence a transaction of any type on any
> other connection.
On Mon, 21 Jan 2019 at 15:46, wrote:
> For the moment, the solution that is working for me is to disable syncing
> with PRAGMA synchronous = OFF. This is acceptable in this particular
> application because a power failure or OS crash will necessitate restarting
> the data gathering process
On 21/01/2019 18:46, andrew.g...@l3t.com wrote:
Okay, I put in some instrumentation. Basically I print out all database
queries as they happen, along with all calls to sqlite3OsLock() and
sqlite3OsUnlock() (including their lockType argument and any abnormal return
code). Also I print out
Okay, I put in some instrumentation. Basically I print out all database
queries as they happen, along with all calls to sqlite3OsLock() and
sqlite3OsUnlock() (including their lockType argument and any abnormal return
code). Also I print out how many times sqlite3InvokeBusyHandler() has to
Keith Medcalf wrote:
> Andy Goth wrote:
>> There are two possibilities:
>>
>> 1. Transactions do work, but I'm misusing them and must learn how to be
>> more careful. In this case, I will update documentation to properly
>> explain their use to others.
>>
>> 2. Transactions don't work, at least
On Sunday, 20 January, 2019 17:19, Simon Slavin wrote:
>> If the issue is the dead lock, you get similar issues with all
>> DBMSes.
> I'm not perfectly sure of my logic here, but OP posted elsewhere that
> replacing BEGIN with BEGIN IMMEDIATE cures the problem. I think this
> indicates that
On 20 Jan 2019, at 11:54pm, Richard Damon wrote:
> If the issue is the dead lock, you get similar issues with all DBMSes.
I'm not perfectly sure of my logic here, but OP posted elsewhere that replacing
BEGIN with BEGIN IMMEDIATE cures the problem. I think this indicates that his
problem
On Sunday, 20 January, 2019 16:32, Thomas Kurz wrote:
>Just for curiosity: how do other DBMS (MySQL, etc.) solve this issue?
>I guess the keypoint is that no matter where the query comes from,
>the database files are always under control of the same process which
>then can take care of the
On 1/20/19 6:32 PM, Thomas Kurz wrote:
> Just for curiosity: how do other DBMS (MySQL, etc.) solve this issue? I guess
> the keypoint is that no matter where the query comes from, the database files
> are always under control of the same process which then can take care of the
> correct order
said, just for curiosity - no offense against SQlite because I can well
understand the problem that SQlite has to deal with :-)
- Original Message -
From: Richard Damon
To: sqlite-users@mailinglists.sqlite.org
Sent: Monday, January 21, 2019, 00:21:48
Subject: [sqlite] Database locking prob
On 1/20/19 4:51 PM, andrew.g...@l3t.com wrote:
> James K. Lowden wrote:
>> On Sat, 19 Jan 2019 08:07:42 -0500 Richard Hipp wrote:
>>> The busy timeout is not working because you start out your transaction
>>> using a read operation - the first SELECT statement - which gets a read
>>> lock. Later
>There are two possibilities:
>1. Transactions do work, but I'm misusing them and must learn how to
>be more careful. In this case, I will update documentation to
>properly explain their use to others.
>2. Transactions don't work, at least not for my task. In this case,
>I will do my best to
James K. Lowden wrote:
> On Sat, 19 Jan 2019 08:07:42 -0500 Richard Hipp wrote:
>> The busy timeout is not working because you start out your transaction
>> using a read operation - the first SELECT statement - which gets a read
>> lock. Later when you go to COMMIT, this has to elevate to a
On Sat, 19 Jan 2019 08:07:42 -0500
Richard Hipp wrote:
> The busy timeout is not working because you start out your transaction
> using a read operation - the first SELECT statement - which gets a
> read lock. Later when you go to COMMIT, this has to elevate to a
> write lock. But SQLite sees
On 19 Jan 2019, at 4:43pm, wrote:
> I'm thinking one possible sequence might be:
It's the right suggestion, but you're still in diagnostic stage, so this is a
faster test:
1) Make sure your code still sets timeouts on every connection. 5000 ms should
be fine.
2) Replace every BEGIN with
> Not sure if this is the problem you are running into, but it might be
> because SQLite is detecting a potential deadlock.
I think that's exactly what's going on. SQLite is not bothering with the busy
handler since it already knows no amount of waiting will solve the problem.
> When you just
Scott Vallery wrote:
> have you considered 'threading'? This sounds like something that you need to
> create a thread to do. Creating a thread should then allow you to set
> parameters to wait until one process completes and switch back and forth.
Yes, threads would make cooperation easier.
On 2019/01/19 5:20 PM, Richard Hipp wrote:
On 1/19/19, R Smith wrote:
"merged at some stage" and "merged into the next release" are
different things. The latter will likely not happen, but I cannot say
about the former, just yet.
Thank you - I believe my original mail did say "... a next
On 1/19/19, R Smith wrote:
> I make scripts/software for SQLite used by many, I
> can dictate the lowest version number for a script, but usually they use
> whatever engine is downloadable from the site (sqlite3.exe, sqlite3.dll
> etc.), so if the very useful BEGIN CONCURRENT won't be merged at
On 2019/01/19 4:55 PM, Richard Hipp wrote:
On 1/19/19, R Smith wrote:
Hi RIchard, any chance this BEGIN CONCURRENT branch will make it into a
next SQLite standard release?
You can always pull it from the branch. The branch will not go away.
Thank you kindly, this much is known.
Allow me
On 1/19/19, R Smith wrote:
> Hi RIchard, any chance this BEGIN CONCURRENT branch will make it into a
> next SQLite standard release?
You can always pull it from the branch. The branch will not go away.
--
D. Richard Hipp
d...@sqlite.org
___
Hi RIchard, any chance this BEGIN CONCURRENT branch will make it into a
next SQLite standard release?
On 2019/01/19 3:07 PM, Richard Hipp wrote:
If you are daring, you can also try building from the begin-concurrent
branch (https://www.sqlite.org/src/timeline?r=begin-concurrent) and
using
Not sure if this is the problem you are running into, but it might be because
SQLite is detecting a potential deadlock. When you just use BEGIN, SQLite
will acquire locks lazily - the first read operation will acquire a shared
lock, and the first write operation will acquire a reserved lock. Any
Thanks for the detailed trouble analysis!
Short answer: Probably you want to do "BEGIN IMMEDIATE" rather than
just "BEGIN" to start your transaction.
The busy timeout is not working because you start out your transaction
using a read operation - the first SELECT statement - which gets a
read
I'm a newbie on the block and this is my first post, but have you considered
'threading'? This sounds like something that you need to create a thread to do.
Creating a thread should then allow you to set parameters to wait until one
process completes and switch back and forth. I've done this
I am having significant difficulty getting two process to not slam into each
other when accessing the same database. The behavior I want is for one process
to wait while the database is busy being written to by the other, but instead I
immediately get SQLITE_BUSY. This is happening to me when
30 matches
Mail list logo
