Hi Simon,
I agree with one connection logic.
scenario: while write request is in progress with 100K records
insertion, new request with reading of 10000 records already existing
records. Here, read request should wait till write request completes. Is it
correct?
Thanks in advance.
Regards,
On Mon, Jul 16, 2012 at 2:29 PM, Simon Slavin <slav...@bigfraud.org> wrote:
>
> On 16 Jul 2012, at 7:50am, Durga D <durga.d...@gmail.com> wrote:
>
> > I am developing readers (> 1) and writer(1) application for sqlite3
> db.
> >
> > I would like to maintain set of connections in application
> > initialization time. whenever read request comes, serve the request from
> > existing connection object like pool.
>
> You can keep one database connection open per application, for the entire
> time that your application runs. This will work correctly.
>
> The API will only service one request at a time. You can prepare a number
> of statements (for example, a number of "SELECT" commands) but SQLite is
> single-threaded and locks the entire database when working. So it will
> work only on one command at a time. So there's no point in doing clever
> things with multiprocessing and background handling of many commands
> because the SQLite API will still be your bottleneck.
>
> > Here, my doubt is: if app. runs for a long time ( one week), will
> > connection maintain latest state of db?
>
> SQLite correctly handles many different apps, users and computers
> accessing the database at once. A change made by one app on one computer
> will be instantly noticed by a different app on a different computer.
>
> 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
