Re: [sqlite] SQLite Suitability for Shopping Cart

[Fred Williams]

Thanks Dr.

I already read that along time ago and fully understand it 100%.  Seems many
others either do not read or do not understand simple straight forward
descriptions of basic functionality.  Or just maybe they ask anyway hoping
someone will say well why not? :-)

Fred
120% happy with SQLite.

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of D. Richard Hipp
Sent: Friday, September 25, 2009 1:12 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] SQLite Suitability for Shopping Cart



On Sep 25, 2009, at 1:13 PM, CityDev wrote:

>
>
> Fred Williams-5 wrote:
>>
>> no further need to ask and answer, "Will SQLite support
>> multi users?
>>
> Maybe it should be covered a bit more specifically on the SQLite site,

http://www.sqlite.org/whentouse.html

> bearing in mind that new people would naturally have the mindset that
> databases are for shared use normally. SQLite does have sharing
> capabilities
> so it would be helpful to profile these for novices.
> --
> View this message in context:
http://www.nabble.com/SQLite-Suitability-for-Shopping-Cart-tp25530589p256157
24.html
> Sent from the SQLite mailing list archive at Nabble.com.
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

D. Richard Hipp
d...@hwaci.com



___
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

Re: [sqlite] SQLite Suitability for Shopping Cart

[Marcus Grimm]

I would like to add also a comment here:

Sqlite perfectly works as a backend for multi
user applications/servers IF they are implemented accordingly.
That is, avoid multible processes/instances that access
the same db file, use one main process and threads instead.
Take care about busy handling etc.
Under this background my application (a client server
database) does work very well using sqlite. I have installations
with 20 user connected to my server, no problem. -- stop.

I hope that such sentenses like "sqlite is not intended
for client/server applications" will be removed from
the sqlite pages as it is too "shy" and to general.
One example, I mentioned using sqlite to one of our partners
and of course they looked at the web pages of sqlite and
found the above statement -- now I run into a defense
issue and have to explain and argue for sqlite.
As a result, I stop explaining that we are using sqlite
because I don't want that customers start to worry
about the sql back end.

Just to share my feeling.. sqlite is a wonderful tool, stop
making it smaller than it is, it doesn't deserve it.

Marcus

>
>
> Fred Williams-5 wrote:
>>
>>  no further need to ask and answer, "Will SQLite support
>> multi users?
>>
> Maybe it should be covered a bit more specifically on the SQLite site,
> bearing in mind that new people would naturally have the mindset that
> databases are for shared use normally. SQLite does have sharing
> capabilities
> so it would be helpful to profile these for novices.
> --
> View this message in context:
> http://www.nabble.com/SQLite-Suitability-for-Shopping-Cart-tp25530589p25615724.html
> Sent from the SQLite mailing list archive at Nabble.com.
>
> ___
> 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

Re: [sqlite] SQLite Suitability for Shopping Cart

[D. Richard Hipp]

On Sep 25, 2009, at 1:13 PM, CityDev wrote:

>
>
> Fred Williams-5 wrote:
>>
>> no further need to ask and answer, "Will SQLite support
>> multi users?
>>
> Maybe it should be covered a bit more specifically on the SQLite site,

http://www.sqlite.org/whentouse.html

> bearing in mind that new people would naturally have the mindset that
> databases are for shared use normally. SQLite does have sharing  
> capabilities
> so it would be helpful to profile these for novices.
> -- 
> View this message in context: 
> http://www.nabble.com/SQLite-Suitability-for-Shopping-Cart-tp25530589p25615724.html
> Sent from the SQLite mailing list archive at Nabble.com.
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Suitability for Shopping Cart

[CityDev]

Fred Williams-5 wrote:
> 
>  no further need to ask and answer, "Will SQLite support
> multi users? 
> 
Maybe it should be covered a bit more specifically on the SQLite site,
bearing in mind that new people would naturally have the mindset that
databases are for shared use normally. SQLite does have sharing capabilities
so it would be helpful to profile these for novices. 
-- 
View this message in context: 
http://www.nabble.com/SQLite-Suitability-for-Shopping-Cart-tp25530589p25615724.html
Sent from the SQLite mailing list archive at Nabble.com.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Suitability for Shopping Cart

[Fred Williams]

Since SLQite was never intended for multi user databases in the initial
design i.e. the name "SQLite" I would say the design is the reason.

Now can the design be reengineered to allow finer grain locking as an option
without derailing the original design intent?  That is for those that do all
the work for the rest of us to decide.

My only incentive that pops readily to mind would be the enormous bandwidth
reduction here with no further need to ask and answer, "Will SQLite support
mulit users? and etc. ad nauseium..." :-)

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of CityDev
Sent: Friday, September 25, 2009 12:58 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] SQLite Suitability for Shopping Cart



This is what is says on the SQLite site:

"We are aware of no other embedded SQL database engine that supports as much
concurrency as SQLite. SQLite allows multiple processes to have the database
file open at once, and for multiple processes to read the database at once.
When any process wants to write, it must lock the entire database file for
the duration of its update. But that normally only takes a few milliseconds.
Other processes just wait on the writer to finish then continue about their
business. Other embedded SQL database engines typically only allow a single
process to connect to the database at once."

What that seems to be saying is you can have concurrency but you will suffer
the effects of whole-database locking for update transactions. It seems a
glaring shortcoming, so either SQLite is not normally used by multiple
processes or people find it doesn't matter too much ie you still get
acceptable performance with n users. Which do you think is true?
--
View this message in context:
http://www.nabble.com/SQLite-Suitability-for-Shopping-Cart-tp25530589p256068
92.html
Sent from the SQLite mailing list archive at Nabble.com.

___
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

Re: [sqlite] SQLite Suitability for Shopping Cart

[Kees Nuyt]

On Thu, 24 Sep 2009 22:58:28 -0700 (PDT), CityDev
 wrote:

>
>This is what is says on the SQLite site:
>
>"We are aware of no other embedded SQL database engine that supports as much
>concurrency as SQLite. SQLite allows multiple processes to have the database
>file open at once, and for multiple processes to read the database at once.
>When any process wants to write, it must lock the entire database file for
>the duration of its update. But that normally only takes a few milliseconds.
>Other processes just wait on the writer to finish then continue about their
>business. Other embedded SQL database engines typically only allow a single
>process to connect to the database at once."
>
>What that seems to be saying is you can have concurrency but you will suffer
>the effects of whole-database locking for update transactions. 

That's what is says, and it's a design decision.

>It seems a glaring shortcoming, 

I wouldn't say so.

>so either 
> 1) SQLite is not normally used by multiple processes or
> 2) people find it doesn't matter too much ie you still
>  get acceptable performance with n users. 
> Which do you think is true?

1) is true. 2) is not false, but doesn't really apply,
considering SQLites "mission statement":

http://www.sqlite.org/whentouse.html
-- 
  (  Kees Nuyt
  )
c[_]
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Suitability for Shopping Cart

[Simon Slavin]

On 25 Sep 2009, at 6:58am, CityDev wrote:

> What that seems to be saying is you can have concurrency but you  
> will suffer
> the effects of whole-database locking for update transactions. It  
> seems a
> glaring shortcoming, so either SQLite is not normally used by multiple
> processes or people find it doesn't matter too much ie you still get
> acceptable performance with n users. Which do you think is true?

The former.  SQLite is the SQL of choice for embedded applications:  
things running inside a smartphone, or a GPS unit or something.  Since  
these units run just one UI application at a time, you don't need to  
worry about sophisticated locking mechanisms.  Only one processor is  
used to run user-aware programs.  If you're running a program to  
consult a database of phone numbers or map features or songs, that's  
the only program that cares about that kind of data.  While you're  
downloading new data for those databases, the entire device is locked  
in 'synch' mode anyway, so no other programs will be running.

Once you've made that design choice, the points Roger mentioned come  
into play: SQLite library calls are designed to let you do as much  
processing as possible before you need to lock the file.  This is not  
true of all SQL engines which will do some processing, lock a record,  
unlock it, do more processing, lock the next record, etc..

SQLite is great for what it's designed for.  But it's not designed for  
complicated multi-user online databases.  You pays your money and you  
gets your choice.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Suitability for Shopping Cart

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CityDev wrote:
> What that seems to be saying is you can have concurrency but you will suffer
> the effects of whole-database locking for update transactions. It seems a
> glaring shortcoming, so either SQLite is not normally used by multiple
> processes or people find it doesn't matter too much ie you still get
> acceptable performance with n users.

Did you notice the use of "embedded" several times?

The SQLite approach is to use simple locking and to hold locks for as short
periods as possible.  An alternate approach which would be more complicated
locking (pages or rows) and having considerably more code to manage
concurrency across processes of that locking.  (That code would be really
nasty as operating systems don't really provide any common primitives of
that level of granularity.  Heck they barely provide file locking.)

If you go with SQLite's flow such as not having open transactions lying
around and getting work done as quickly as possible (eg composing SQL
upfront rather than long periods thinking about what to issue next within a
transaction) then it will work *very* well.  Chances are it will
significantly outperform database "servers", as they require marshalling of
queries and responses between processes and possibly over the network -
something which will be way slower than SQLite's quick transactions.
(SQLite was originally started because of database servers being flaky and
needing administration.)

Roger


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkq8apMACgkQmOOfHg372QSH+ACguuHaLxS7CoPE/yjTXrKI/r3u
TKYAoNOcv4Gtw9BL6iHsz31DWZQKI8fs
=OMAn
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Suitability for Shopping Cart

[Dan Kennedy]

On Sep 24, 2009, at 7:04 PM, CityDev wrote:

>
> Thanks for that Sebastian.
>
> It does however surprise me. I believe Access Jet handles simultaneous
> activities. Indeed I've got a feeling it does row-locking rather than
> page-locking. It's odd that SQLite has such a limitation. Anyway,  
> you've
> saved me a lot of heartache.

It changed from page to row locking in version 4.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Suitability for Shopping Cart

[CityDev]

Thanks for that Sebastian. 

It does however surprise me. I believe Access Jet handles simultaneous
activities. Indeed I've got a feeling it does row-locking rather than
page-locking. It's odd that SQLite has such a limitation. Anyway, you've
saved me a lot of heartache.
-- 
View this message in context: 
http://www.nabble.com/SQLite-Suitability-for-Shopping-Cart-tp25530589p25562183.html
Sent from the SQLite mailing list archive at Nabble.com.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Suitability for Shopping Cart

[Sebastian Bermudez]

No ! use mysql
that Concurrency on sqlite have high depend... from HW. (sqlite handles 
transaction one at time !)... 100 Concurrent Tx. (5 sec. each one)...the last 
pooled user must to wait 500 sec... to complete



--- El mar 22-sep-09, CityDev <nab...@recitel.net> escribió:

> De: CityDev <nab...@recitel.net>
> Asunto: [sqlite]  SQLite Suitability for Shopping Cart
> Para: sqlite-users@sqlite.org
> Fecha: martes, 22 de septiembre de 2009, 3:37 am
> 
> I am building a shopping cart application that calls a web
> service which
> provides lists of documents and the documents themselves.
> The user purchases
> document images. The application will load lists into a
> database, then build
> pages from the stored lists. The database will also keep
> track of
> application state and store the retrieved documents for a
> month. It must be
> capable of supporting 100 simultaneous users. The maximum
> list size is 8000
> documents which takes about 5 minutes to load from the web
> service (in 5
> second transactions). There will be more than one front end
> server.
> 
> From this description, do you think SQLite is a valid
> choice as the database
> in this scenario?
> -- 
> View this message in context: 
> http://www.nabble.com/SQLite-Suitability-for-Shopping-Cart-tp25530589p25530589.html
> Sent from the SQLite mailing list archive at Nabble.com.
> 
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> 


  Yahoo! Cocina

Encontra las mejores recetas con Yahoo! Cocina.


http://ar.mujer.yahoo.com/cocina/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite Suitability for Shopping Cart

[CityDev]

I am building a shopping cart application that calls a web service which
provides lists of documents and the documents themselves. The user purchases
document images. The application will load lists into a database, then build
pages from the stored lists. The database will also keep track of
application state and store the retrieved documents for a month. It must be
capable of supporting 100 simultaneous users. The maximum list size is 8000
documents which takes about 5 minutes to load from the web service (in 5
second transactions). There will be more than one front end server.

>From this description, do you think SQLite is a valid choice as the database
in this scenario?
-- 
View this message in context: 
http://www.nabble.com/SQLite-Suitability-for-Shopping-Cart-tp25530589p25530589.html
Sent from the SQLite mailing list archive at Nabble.com.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users