You have taken a description from the wiki pages of sqlite.org web
site where anyone can post comments and/or suggestions.
Our work is completely different and independent from the comments
you can find into the sqlite web site.
We stress tested the server with 100 concurrent writers are writing
to the same table at the same time and everything was really fast and
smooth.
If you have a solution you want to test I am more than happy to
assist you so you can perform your own tests with the REALSQLServer.
---
Marco Bambini
http://www.sqlabs.net
http://www.sqlabs.net/blog/
On Jul 26, 2006, at 1:15 AM, Kim Kohen wrote:
On 26/07/2006, at 12:13 AM, Marco Bambini wrote:
We took sqlite (the single user version) and we highly modify it
in order to support high concurrency and multiple users working at
the same time on the same database, and you can use this new
product using the new REALSQLServer and REALSQLDatabaseServer class.
••••
Does the work you've done overcomes the limitations described on
the SQLite.org web site?
Snippets from the SQLite web site:
====================================
Situations Where Another RDBMS May Work Better
Client/Server Applications
If you have many client programs accessing a common database over a
network, you should consider using a client/server database engine
instead of SQLite. (snipped stuff about database corruption etc)
A good rule of thumb is that you should avoid using SQLite in
situations where the same database will be accessed simultaneously
from many computers over a network filesystem.
High-volume Websites
SQLite will normally work fine as the database backend to a
website. But if you website is so busy that your are thinking of
splitting the database component off onto a separate machine, then
you should definitely consider using an enterprise-class client/
server database engine instead of SQLite.
High Concurrency
SQLite uses reader/writer locks on the entire database file. That
means if any process is reading from any part of the database, all
other processes are prevented from writing any other part of the
database.
====================================
From this it appears for multiple users there are some built in
limitations. For web applications it seems fine until traffic gets
high enough to warrant sharing the load over multiple servers. The
locking is at the database level so all other queries, inserts etc
are locked whilst any other is being performed - even if to a
different table. Is this correct?
cheers
kim
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
