Eduardo <[EMAIL PROTECTED]> wrote:
Isn't better lock the database while a transaction that can make a
SQLITE_SCHEMA error, as is done with writes? A change in database is
........
first sqlite3_step succeeds, an implicit transaction is started
(I assume there are no explicit transactions in effect), so the
schema can no longer change unexpectedly.
Well, the write was an example. So, a lock_schema wouldn't do the
work at the prepare phase? The schema begins locked and when a
transaction needs to do a change, sends a signal to gain exclusive,
unlock, make the changes and lock it again. Don't know how many cpu
cycles can this take but in a heavy scenario it may be less than
re-prepare, in some cases reparse, the other threaded transactions.
Must add that doing this way you don't need to modify the API.
------------------------------------------------------------------------------------------------------------------------------------------------------------
#The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ;
mount ; fsck ; more ; yes ; umount ; sleep
