On 1/16/15, James K. Lowden wrote:
> On Sat, 10 Jan 2015 00:58:25 -0700
> "Keith Medcalf" wrote:
>
>> > there's no way to hook two SELECTs together to make them see one
>> >database state. That's what JOIN is for. :-)
>>
>> Yes, it is a part of the SQL Standard isolation levels in excess of
>> t
On Sat, 10 Jan 2015 00:58:25 -0700
"Keith Medcalf" wrote:
> > there's no way to hook two SELECTs together to make them see one
> >database state. That's what JOIN is for. :-)
>
> Yes, it is a part of the SQL Standard isolation levels in excess of
> the default default of READ COMMITTED. Differ
On Friday, 9 January, 2015 16:43, James K. Lowden
said:
>On Wed, 07 Jan 2015 21:47:24 -0700 "Keith Medcalf" wrote:
>Along the same lines, since you mentioned it,
>> in an SQLite database you can do:
>> BEGIN
>> SELECT ...
>> SELECT ...
>> SELECT ...
>> SELECT ...
>> COMMIT
>> and the view
On Wed, 07 Jan 2015 21:47:24 -0700
"Keith Medcalf" wrote:
> >As I said, your description (which I trust is accurate) is very
> >helpful to someone who wants to understand how SQLite will act on
> >the SQL provided to it. But it also protrays problematic choices
> >that stray from SQL's defined b
Thanks for all the sage observations. As a server with a connection pool, I'm
avoiding some of issues brought up. Every thread has their own connection
handle and when done, it goes back into the pool so no sharing. I spent some
hours reading everything I could find about this product and concurren
On Wednesday, 7 January, 2015 22:57, Kevin Benson
said:
>-- The OP wrote:
>On Thu, Dec 25, 2014 at 7:32 AM, Rick Kelly wrote:
>>*SNIP*
>> The database file is located in the same folder as the server. The
>server
>is
>> multi-threaded. I'm using library version 3.8.7.4
>> The database file is
On Wed, Jan 7, 2015 at 11:47 PM, Keith Medcalf wrote:
> On Wednesday, 7 January, 2015 20:01, James K. Lowden <
> jklow...@schemamania.org> said:
> >On Fri, 02 Jan 2015 21:41:02 -0700
> >"Keith Medcalf" wrote:
> >> On Friday, 2 January, 2015 16:26, James K. Lowden
> >> said:
> >>
> >> >On Thu, 2
On Wednesday, 7 January, 2015 20:01, James K. Lowden
said:
>On Fri, 02 Jan 2015 21:41:02 -0700
>"Keith Medcalf" wrote:
>> On Friday, 2 January, 2015 16:26, James K. Lowden
>> said:
>>
>> >On Thu, 25 Dec 2014 05:32:45 -0700 (MST) Rick Kelly
>> > wrote:
>>
>> >> All SELECT type requests are wrapp
On Fri, 02 Jan 2015 21:41:02 -0700
"Keith Medcalf" wrote:
> On Friday, 2 January, 2015 16:26, James K. Lowden
> said:
>
> >On Thu, 25 Dec 2014 05:32:45 -0700 (MST) Rick Kelly
> > wrote:
>
> >> All SELECT type requests are wrapped with BEGIN TRANSACTION/COMMIT
>
> >That shouldn't be necessary a
On 3 Jan 2015, at 4:41am, Keith Medcalf wrote:
> I do not believe that there is a way to specify "COMMIT BUT MAINTAIN THE
> SHARED LOCK", (that is, to commit the changes only and un-escalate the lock
> back to a shared lock) which would be required in order for the loop
> semantics posited by
On Friday, 2 January, 2015 16:26, James K. Lowden
said:
>On Thu, 25 Dec 2014 05:32:45 -0700 (MST) Rick Kelly wrote:
>> All SELECT type requests are wrapped with BEGIN TRANSACTION/COMMIT
>That shouldn't be necessary and afaik isn't necessary. SELECT does not
>modify the database. To "commi
On Fri, Jan 2, 2015 at 3:25 PM, James K. Lowden
wrote:
> On Thu, 25 Dec 2014 05:32:45 -0700 (MST)
> Rick Kelly wrote:
>
> > All SELECT type requests are wrapped with BEGIN TRANSACTION/COMMIT
>
> That shouldn't be necessary and afaik isn't necessary. SELECT does not
> modify the database. To "c
On Thu, 25 Dec 2014 05:32:45 -0700 (MST)
Rick Kelly wrote:
> All SELECT type requests are wrapped with BEGIN TRANSACTION/COMMIT
That shouldn't be necessary and afaik isn't necessary. SELECT does not
modify the database. To "commit a select" is to apply the nonchanges.
A common misconceptio
Clients know nothing about the database, they just submit a request and get
results. The server is the only process accessing and using SQLite.
Rick Kelly
--
View this message in context:
http://sqlite.1065341.n5.nabble.com/Client-Server-Best-Practices-tp79728p79731.html
Sent from the SQLite m
On 25 Dec 2014, at 12:32pm, Rick Kelly wrote:
> If a request encounters %SQLITE_BUSY or %SQLITE_LOCKED, I'm retrying up to 5
> times with a 100ms sleep in between.
>
> Will this approach minimize %SQLITE_BUSY and %SQLITE_LOCKED situations and
> provide decent concurrency and long term stability
On Thu, Dec 25, 2014 at 7:32 AM, Rick Kelly wrote:
> I'm using SQLite3 for the first time and am looking to see if those more
> experienced can look at my deployment and offer suggestions.
>
> I have a client/server application running on MS Windows communicating over
> TCP/IP supporting a few do
I'm using SQLite3 for the first time and am looking to see if those more
experienced can look at my deployment and offer suggestions.
I have a client/server application running on MS Windows communicating over
TCP/IP supporting a few dozen clients. Basically, clients send a request to
the server a
17 matches
Mail list logo
