G'day, Given the implementation of a cache spill in sqlite 3.0 putting the database into a blocking state I would like to suggest the following addition to the API:
void sqlite3_spill_handler(sqlite3*, int, int(*)(void*), void*); This addition would register a function to be called whenever an internal page spill was detected. This indicates that an exclusive lock is now held on the database, and readers are now blocked out. In a "realtime" database, where the important thing is to get a bunch of data into the database as its created "BEGIN" and "COMMIT" statements are sent to sqlite essentially only to improve performance. In a spill situation an extra commit could be sent to sqlite (or scheduled to be sent) as soon as possible to again allow readers access. In a non-"realtime" database, the function could also be useful. It (or a variant) could be used to monitor the cache usage of sqlite so applications or their developers could tune the cache usage to minimise spills. In this mode, perhaps an extra function such as the following could be useful: int sqlite3_peak_cache_usage(void); This function could report the peak cache usage of the last sqlite_exec invocation, or the peak cache usage through the sqlite3* lifetime. Benjamin. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
