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
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
I'm jumping into the middle of the conversation, possibly without seeing the
beginning, but from what I've seen so far, it seems to me that the key is
recognizing there are many tools in a programmer's toolbox. Each tool covers a
certain area of functionality really well, then there are areas
Dennis Clarke wrote:
> On 1/19/19 4:47 PM, Andy Goth wrote:
>> Dennis Clarke wrote:
>>> On 2018-07-28 08:33, Andy Goth wrote:
SQLite 3.24.0 fails to build on Solaris 9 (a.k.a. Solaris 2.9)
>>
>>> It may be [worth] while to spin up a Solaris 9 zone on a Solaris 10
>>> or Solaris 11 server for
David Bicking wrote:
> I have a data file with JSON data, and I want to get the data into an
> sqlite database so I can run queries against it. It is not a large file,
> only about 600 records in the main table. I've never worked with JSON
> before, and really don't want to write my own parser to
Richard Hipp wrote:
> On 1/19/19, andrew.g...@l3t.com wrote:
> > I was actually thinking about this earlier today, how I'd signed the
> > contributor agreement for SQLite at the same time as I did for Fossil,
> > yet only ever asked for commit access for Fossil. Would you consider
> > letting me
Richard Hipp wrote:
> Here's the deal: I'm very fussy about who can contribute *code* to
> SQLite, in order to protect the public-domain status of the SQLite
> source code and due to the intense nature of testing required to land a
> change.
Sensible. I was wondering about your policy here,
> 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.
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
11 matches
Mail list logo
