Re: [sqlite] Pager modification question

2007-01-12 Thread Ken
Peter, I'm in agreement with you, as you say as long as it doesn't loose its core features. John, Its not that I want different. Its that sqlite could be made capable of handling internal synchronization. I certainly don't wish to loose the embedded capability nor its simplicity. I do

Re: [sqlite] Pager modification question

2007-01-12 Thread John Stanton
If you want to share a file you have to be able to synchronize access in some way. The POSIX type file locks permit you to do it quite well by giving read and write locks. If you want shared access to a file from multiple processes you either need some form of co-operative lock like a

Re: [sqlite] Pager modification question

2007-01-12 Thread Peter James
On 1/12/07, Ken <[EMAIL PROTECTED]> wrote: If it is a replacement for fopen, then why does it perform locking at all? Since sqlite has implemented threading and multiple connections, then the next logical step in its evoloution is to enable advanced locking techniques for even greater degrees

Re: [sqlite] Pager modification question

2007-01-12 Thread Ken
If it is a replacement for fopen, then why does it perform locking at all? Since sqlite has implemented threading and multiple connections, then the next logical step in its evoloution is to enable advanced locking techniques for even greater degrees of improved concurrency. Ken John

Re: [sqlite] Pager modification question

2007-01-12 Thread John Stanton
If Sqlite were to implement its own locking then it would lose simplicity and versatility. A good way to regard Sqlite is a replacement for fopen. It is a way an application can access a single file. If you want more than that you are not looking for "'lite" and should go straight to

Re: [sqlite] Pager modification question

2007-01-12 Thread Ken
Regarding the locking: Yes certainly only within a single process architecture. I understand that SQLITE is usein g file locks to co-ordinate multiple process locks for unix is fcntl. (Fcntl is an ugly beast, imho sqlite would be better served managing locks internally). I guess there

Re: [sqlite] Pager modification question

2007-01-12 Thread Ken
Regarding the Journal: I was thinking that this would be useful in the context of a single process multiple threads and shared cache. All that would be required is an additional thread to handle the logging. Christian Smith <[EMAIL PROTECTED]> wrote: Ken uttered: > Would it be possible

Re: [sqlite] Pager modification question

2007-01-12 Thread Christian Smith
Ken uttered: Would it be possible to implement a Page level locking system using sqlite? Deadlock detection/recovery and/or prevention is much more complex for page level locking. As there is no shared data between SQLite clients other than the database file itself, tracking locks in other

[sqlite] Pager modification question

2007-01-11 Thread Ken
Would it be possible to implement a Page level locking system using sqlite? I seem to recall a commercial product Ingress that utilized a page level locking scheme that would escalte to a table level lock when over a certain % of a tables pages were locked. This obviously would be very