On Thu, 6 May 2004, Thomas, Basil wrote: >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.
Can you not implement batching of writes into single small transactions? Why do you need "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). There has been discussion of essentially using snapshots to support concurrent readers/writer (readers take a snapshot from before the writer started.) That way, a writer will not affect the operation of readers, but this is will be a 3.0 at the very earliest, if at all. Not sure how DRH is getting on with that. A suggested solution is documented here: http://www.sqlite.org/cvstrac/wiki?p=BlueSky Christian > > >-----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 / \ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
