Thanx The main reason for file locking is to support win95/98/ME???... I do have a server process running and have embedded sqlite to be used by individual threads that may be started. All writes currently go to one writer thread and this seems to work fine. The application we have developed basically creates a virtual xml storage using SQLite as the backing store. When documents are small, transactions do not slow concurrency that much but once in a while we may import a large document or update many small documents at once, we have noticed a large decrease in concurrency as all reader threads are blocked until the write thread that is in a transaction completes. One way we have gotten around this is to implement multiple collections of documents with each collection stored in one database. Implementing each virtual document as a single file/db is out of the question as we have thousands of documents stored already in each collection. All the other features in SQLite are too good for me to abandon just for lack of higher concurrency. Since I have read a lot of suggestions to improve concurrency for ver 3.0, can you tell me what will be changed if anything in version 3.0 as regards increased concurrency???
-----Original Message----- From: D. Richard Hipp [mailto:[EMAIL PROTECTED] Sent: Thursday, May 06, 2004 12:23 PM To: [EMAIL PROTECTED] Subject: Re: [sqlite] vers 3.0 concurrency issues Thomas, Basil wrote: > 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). > Page-level locking will not help. For one thing, we cannot do both page-level locking and reader/writer locks on win95/98/ME. Presumably, reader/writer locks are more desirable than page locks and we are not yet ready to abandon win95/98/ME. (You can do both on unix and winNT/2K/XP.) But more importantly, locking is less than half the problem. The hard part is not locking but recovering from a program crash or OS crash or power failure. If we didn't have to deal with crashes and power failures, doing page-level or row-level locking would be (relatively) easy. In version 3.0, you will be able to ATTACH multiple databases and update them all at once (and atomicially). Then if you put each of your tables in a separate database file and ATTACH them as needed, the end result will be something very like table-level locking. Without a central server process to coordinate things, getting any more concurrency than that is not a viable option, as far as I can determine. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 --------------------------------------------------------------------- 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. ============================================================
