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. ============================================================
