Hi Marc, "Marc L. Allen" <mlal...@outsitenetworks.com> writes:
> If I understand correctly, the purpose of the overall mutex is to prevent a > page from being removed underneath a user. If the standard DB locking > semantics are working properly, I think there is no possibility of a page's > data from being modified underneath another user. Yes, that's my understanding also. This is all taken care of at higher (transaction and table) locking levels. > If the above it true, cache protection semantics are strictly concerned with > page management. That is, a page is requested that is not in the cache and > needs to be inserted into it. If the cache is full, another page needs to > be released. All that is required is protecting pages currently in use from > being released. > > I think, instead of a mutex serializing access to the entire cache, all > that is needed is a mutex serializing access to the cache meta-data and > the use of reference counts to help the page replacement algorithm make > a good choice in which page to remove. All sounds very sensible to me. Boris -- Boris Kolpackov, Code Synthesis http://codesynthesis.com/~boris/blog Compiler-based ORM system for C++ http://codesynthesis.com/products/odb Open-source XML data binding for C++ http://codesynthesis.com/products/xsd XML data binding for embedded systems http://codesynthesis.com/products/xsde _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
