RE: [sqlite] vers 3.0 concurrency issues

2004-05-06 Thread Thomas, Basil
I am using SQLite expressly because of its type less data schema and large
text field support.
The application we have developed is using SQLite exactly as an embedded
database and would require
an extremely large re-write because of all the good features included in
SQLite. The ONLY feature missing
is "higher" concurrency when using transactions. 
I have already implemented a solution using the application using MS SQL
Server/Sybase and
SQLite is at least a hundred times faster. The problem is when implementing
"long" transactions.
When there is only a maximum of one user/thread, there are no long
transactions as a transaction can take as long as it likes. Transaction
length is only a problem as more users concurrently use the database. 
I am not looking for a perfect solution as SQLite is great already, just
higher concurrency.
I am no technical expert but...could not page locking at least be
implemented by the pager module to increase concurrency(very naive...but
better than file locking).


-Original Message-
From: Christian Smith [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 06, 2004 9:38 AM
To: Thomas, Basil
Cc: [EMAIL PROTECTED]
Subject: Re: [sqlite] vers 3.0 concurrency issues


On Thu, 6 May 2004 [EMAIL PROTECTED] wrote:

>
>I would like to use SQLite on a web server or .net remoting and
>multi-user/threads may become an issue
>as locking is based at the finest granularity of file locking instead of
>table/page/row locking. Will this issue be resolved from 3.x onwards so
that
>concurrency can be increased when multiple users
>are connecting to the db?
>SQLite is extremely fast in single process/thread mode and because of this
>success, more users would like to access the application. File locking is
>too similar to MS Access and we have had all kinds of problems
>supporting multiple users on a network drive. Ideally I would first like to
>implement SQLite as part of an ISAPI dll so it could be accessed using http
>to an IIS web server.
>Any suggestions or solutions to running SQLite in multi-threaded
environment
>with potentially high concurrency???

SQLite already supports concurrent readers. If most access is read only,
and writes are short and/or infrequent, then SQLite might continue to fit
the bill.

But, use the right tool for the job. If you require concurrent
readers/writer(s), then you may be better off using a full blown
client/server database, especially in a distributed environment. SQLite is
designed to be embedded, don't just use it because you can.

I believe there may be some work in 3.0 to allow concurrent readers with
single writer, but that is likely to be within a single address space
only, if at all.


>B.Thomas
>
>-Original Message-
>From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, May 04, 2004 1:56 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [sqlite] release 14
>
>
>aducom wrote:
>> Hi,
>>
>> Is it possible to do a release 14 of the sqlite.dll with the support of
>> real blobs? (It's available in cvs?) Or will I have to wait for the
>> full new version?
>>
>
>I don't know what you mean by "support for real blobs".  You'll need
>to be much more specific.
>
>Generally speaking, no new features will be added to SQLite 2.8.13.
>What you see is what you get.  New features go into SQLite 3.0.0.
>

-- 
/"\
\ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
 X   - AGAINST MS ATTACHMENTS
/ \

This e-mail may be 
privileged and/or confidential, and the sender does not waive any related rights and 
obligations. Any distribution, use or copying of this e-mail or the information it 
contains by other than an intended recipient is unauthorized. If you received this 
e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux 
droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce 
message ou des renseignements qu'il contient par une personne autre que le (les) 
destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par 
erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par 
un autre moyen.



RE: [sqlite] Exists keyword and corelated subqueries

2004-04-16 Thread Thomas, Basil
I think once SQLite ver 3.0 stabilizes, all of the enhancements to the SQL
language
capabilities will be addressed then. Once the the file format and low level
engine
enhancements are in production, I am sure many of us will want more
compliant SQL
code similar to SQL Server/Oracle/Sybase/MySQL/etc... but streamlined using
the KISS
principle that SQLite follows...

-Original Message-
From: Kurt Welgehausen [mailto:[EMAIL PROTECTED]
Sent: Friday, April 16, 2004 12:31 PM
To: [EMAIL PROTECTED]
Subject: Re: [sqlite] Exists keyword and corelated subqueries


> Any chance of their being added ... ?

I doubt it; there have been lots of proposals for changes and
additions flying around, but these points haven't come up (as
best I can recall).

Regards


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


This e-mail may be
privileged and/or confidential, and the sender does not waive any related
rights and obligations. Any distribution, use or copying of this e-mail or the
information it contains by other than an intended recipient is unauthorized.
If you received this e-mail in error, please advise me (by return e-mail or
otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce
pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation
ou copie de ce message ou des renseignements qu'il contient par une personne
autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez
ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par
retour de courrier électronique ou par un autre moyen.



[sqlite] reading tables from api function call

2004-02-10 Thread Thomas, Basil
Is it possible to read a table from a api function call without executing a sql 
statement that returns the table as 
a resultset?? I would like to do a index nested loop join specifically based on info 
in the table that simulates the tree structure of an XML document. 
[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]