> I think "single writer, multiple readers" is the simplest way to describe
sqlite's approach to isolation
I’m not sure if this summarization paints enough of a picture about how SQLite
restricts interleaving of read & write operations between concurrent
transactions, to guarantee isolation.
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
There are a few reasons for putting code in a DYNAMIC link library (linked at
runtime) versus statically linked into the application (the same applies to all
operating systems that support runtime linkage no matter what they call the
runtime linked modules):
1) You need to be able to replace
Just curious as to why you wouldn't choose option #2 - as that's what I use
with my VB .NET applications, which work quite well. Just distribute the
.exe, then the two SQLite DLLs (well, three technically, as there are two
versions of the interop.dll)
Thanks,
Chris
On Mon, Jan 21, 2019 at 4:19
On 21 Jan 2019, at 11:16am, J Decker wrote:
> 4. Statically linked to and compiled with your datalayer code.
What he said. Also, you should be using the 'Amalgamation' download to do
this, unless you need some compiler switches which are not supported by that
source-set.
Simon.
> There seems to be a few misconceptions in the article regarding the
> difference between DEFERRED/IMMEDIATE/EXCLUSIVE
Looks like I mistakes in the 2PL section, it had contradictory content about
`RESERVED` locks. Thanks for your feedback, have pushed corrections.
> Specifically, your
On Mon, Jan 21, 2019 at 2:16 AM John Smith wrote:
> Hi,
>
>
> I need to build a data-layer DLL for a large project.
>
> My project is 64-bit built with Visual-Studio 2015.
>
> I want to ask about what would be the preferred way to build SQLite:
>
> 1. Build SQLite code as a separate DLL and use
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
Hi,
I need to build a data-layer DLL for a large project.
My project is 64-bit built with Visual-Studio 2015.
I want to ask about what would be the preferred way to build SQLite:
1. Build SQLite code as a separate DLL and use it from my data-layer DLL,
2. Use the ready-built binary of
On Tue, 15 Jan 2019 at 02:54, Simon Slavin wrote:
> The "just-in-time" idea mentioned in your question doesn't work in real
> life, since constantly checking mutex status keeps one core completely
> busy, using lots of power and generating lots of heat.
>
Technically "just-in-time" could be
There seems to be a few misconceptions in the article regarding the
difference between DEFERRED/IMMEDIATE/EXCLUSIVE, and the fine details of
how different lock states interact.
Specifically, your diagrams suggest that once a writer obtains a RESERVED
lock (as happens when an IMMEDIATE transaction
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
16 matches
Mail list logo
