No. Apache uses a worker process pool where each forked worker process contains one or more service threads. Each concurrent http operation is dispatched to a separate thread (which may only comprise one thread per process). The worker service model is serially entrant. So you would need one connection per service thread. Processes are not created and destroyed around each http operation, now are threads created and destoryed. When a new worker process is needed, it is forked and then does its long initialization process including starting and initializing however many service threads are allocated per process. When the number of workers in the pool needs to be decreased (because it is no longer needed for the past several minutes) then the expensive close operations are performed which spins down all the threads and releases all the long held resources needed by that worker process. Neither processes nor threads are created and destroyed willy nilly per request.
>-----Original Message----- >From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- >boun...@sqlite.org] On Behalf Of Simon Slavin >Sent: Saturday, 6 September, 2014 21:13 >To: General Discussion of SQLite Database >Subject: Re: [sqlite] Transactions for read operations > > >On 7 Sep 2014, at 3:49am, Keith Medcalf <kmedc...@dessus.com> wrote: > >> You say "the database connection". Did you use the language >imprecisely or are you using only one database connection? One presumes >that you may have half-a-million pages and half-a-billion concurrent HTTP >operations, in which case you will have significant multi-leaving of >operations. Or is your server single threaded and can only answer one >HTTP operation at a time? > >Apache creates a separate process to reply to each page request. If you >have Apache replying to half-a-billion concurrent HTTP requests, you will >have half-a-billion processes. (Presumably on many different computers >in a web farm.) If you're using PHP to access your SQLite database file, >each process would open its own connection to the database. That's how >it works, and it works fine on small and medium-power web hosts. > >That many connections would be impossible for SQLite, of course. But if >your web host has half-a-billion concurrent HTTP operations your multiple >web hosts will be using Postgres or some other client/server DBMS, not >SQLite. > >Simon. >_______________________________________________ >sqlite-users mailing list >sqlite-users@sqlite.org >http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users