[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] Using SQLite in threadly Web server applications
From:       John Stanton <johns () viacognis ! com>
Date:       2006-10-30 15:44:55
Message-ID: 45461DF7.4000405 () viacognis ! com
[Download RAW message or body]

At some point shared usage of a single resource involves some form of 
synchronization.  If you use Sqlite the you need to add that capability 
somehow.  Sqlite lets you use file locks fairly simply for that purpose 
if that suits your application.

An alternative is to use something like PostgreSQL or Oracle which 
incorporate the extra layers of software but, ipso facto, lack the 
simplicity of Sqlite.

The problem is not so strange, as Dr Hipp points out.  Using Sqlite as a 
shared resource is just like using a file as a shared resource.  If you 
take his advice that Sqlite is not a replacement for DB/2 or Oracle but 
a replacement for fopen you understand the problem.

We find Sqlite to be a remarkable tool because it implements either a 
small embedded database or becomes part of a lightweight implementation 
of a special purpose multiple user database where the resource sharing 
is tailored to the application and the overhead of an enterprise level 
DBMS is thereby avoided.

David Gewirtz wrote:
>  
> Those suggestions are great. For something like log analysis, there's no
> problem either reading in log file tails ever so often or queuing up a
> single thread to give more real-time access. I think I'm leaning towards a
> more real-time view, but I might take the tail option if it codes easier.
> 
> On the topic of threads, though, this does open a pile of other "running
> behind a Web server" sort of operations:
> 
> * To keep a db of user authentication data in an SQLite db, users will need
> some level of real-time response to logins
> 
> * To keep a db of, say, a discussion forum, user posts will need to be
> written and made available in realish-time
> 
> * To update Web pages dynamically with information populated from a user's
> preference or users' usage patterns, the page will need to be generated in
> real time
> 
> And each of these interactions with the server will occur with different
> user sessions in different threads. Can SQLite be used to build applications
> that do the operations above? Do I need to do some single-thread queue
> structure for each approach?
> 
> I'd love some guiding thoughts on these things to help understand how to
> really approach the problem.
> 
> Thanks!
> 
> -- David
> 
> 
> 
> -----------------------------------------------------------------------------
> To unsubscribe, send email to sqlite-users-unsubscribe@sqlite.org
> -----------------------------------------------------------------------------
> 


-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe@sqlite.org
-----------------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]