Igor Mironchick wrote:
How about the case of a simple BEGIN which sets a deferred lock so
that the busy will occur when that lock is promoted later in the the
transaction?
As I understand it the deferred lock capability is conducive to better
concurrency, but does have other effects requiring that provision be
made to intercept a BUSY in the body of the transaction.
Ok. But this situation are more preferable for me that "BEGIN EXCLUSIVE".
What about this:
char * errors;
// I guarante that here no errors in SQL syntaxis.
char * sql = "SELECT * FROM data";
sqlite3_exec( db, "BEGIN", 0, 0, 0 );
int ret = sqlite3_exec( db, sql, 0, 0, &errors );
while( ret != SQLITE_OK )
{
std::cerr << "There is some errors while executing SQL statement: "
<< errors << std::endl;
sqlite3_free( errors );
ret = sqlite3_exec( db, sql, 0, 0, &errors );
}
sqlite3_exec( db, "END", 0, 0, 0 );
More dangerous when "COMMIT" after "INSERT" return SQLITE_BUSY!!!
Your BEGIN tries to set a RESERVED lock, but only one RESERVED lock is
permitted so your BEGIN may fail.
BTW, I suggest that you do not use sqlite3_exec on new programs and use
sqlite3_prepare and sqlite3_step. It is the preferred interface.
Sqlite3_exec is deprecated and exists for legacy applications.
See here for a locking description:
http://www.sqlite.org/lockingv3.html
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
