On 2013/11/11 08:40, Raheel Gupta wrote:
I guess a Row level locking could be difficult but a Page Level locking
could be not that difficult.
ATM "db level locking" :
If DB locked throw busy error
In not locked lock db, let the writer do its thing
For Page level locking (I think you could allow something like) :
Let writer write / modify pages IF not locked
ONLY If writer comes across a locked page wait for it to be released
In this way, multiple threads could do writes. Again I am not an expert but
from my little understanding this might not remove the leaness. You are the
expert.
And even I agree that Sqlite must be "lite"
It's rare to see a drum banged this hard, so let me commend you for persistance and explain a bit more what Simon and others were
trying to enlighten you about.
SQLite does not have row-level locking because when it was conceived at the onset, and then again every time it was updated to a
newer major version (We are at 3 now), the people who designed it sat around their desks and brainstormed about which features can
be included, which cannot and why. Whether it be space costs or costs paid to the processing cycles or for whatever reason, they
have decided every time that row-level locking comes at too high a price for this kind of database - much in the same way the
F1-McLaren racing team does not add airconditioning or CD-players to their cars, even though some F1 drivers would no-doubt enjoy a
bit of luxury. This is not dissimilar to MySQL ISAM tables which, for much the same reasons do not offer row-level locking. Anyone
who uses MySQL seriously would have their large Databases contain a mix of ISAM and Inno Tables - whichever tool is best for the job.
SQLite is a tool, one of the many available, one of the best, but it has a niche and a specific job. If you truly cannot live
without row-level locking, you could well use MySQL or PostGRES etc - these are equally free. But if you need speed, local-file
access and embeddibility (if that's a word) then you need SQLite.
I know it is easy to sit on the sideline and imagine that row-locking would be easy, or as your newest post suggests, page-level
locking - but you have an entire working and tested structure designed in ways that specifically is NOT row/page-locking, to even
simply change that to be able to do so, then test it and risk all the backward compatibility issues that surround it, and then
explain to everyone how it all works a bit slower now, but at least you can lock pages... just won't work. It's like trying to
convince the mentioned F1 team that they should really run Diesel-Engines because it is more efficient (which isn't a lie), or
simply add 36-inch wheels to their cars, like buses have, because it lasts longer (again, not a lie). I am using wayward examples
to try and make it clear how your suggestions look to the engineers making the engine.
Tell you what though, if you can download a copy of the code, and implement working and stable row or page-level locking with minor
increases in size and negligible decreases in performance, I am willing to bet they will consider implementing it (at least in
SQLIte4) and probably make you famous for it - but I must confess, there is not a lot of anticipation.
Please know I'm not scolding in any way (if it might seem like it), only telling you this because we all fall into the trap of
thinking things can work better easily - me too.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
