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.
Not true.
BTW:
"The SQL command "BEGIN TRANSACTION" (the TRANSACTION keyword is
optional) is used to take SQLite out of autocommit mode. Note that the
BEGIN command does not acquire any locks on the database. After a BEGIN
command, a SHARED lock will be acquired when the first SELECT statement
is executed. A RESERVED lock will be acquired when the first INSERT,
UPDATE, or DELETE statement is executed. No EXCLUSIVE lock is acquired
until either the memory cache fills up and must be spilled to disk or
until the transaction commits. In this way, the system delays blocking
read access to the file file until the last possible moment."
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.
sqlite3_exec not deprecated but preferable to use. But I don't see any
advantages in PREPARE/STEP when SQL statement so simple and will not
used anymore with another variabled params...
--
Regards,
Igor Mironchick,
Intervale ©
#ICQ 492-597-570
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
