On Wednesday, 31 July, 2019 10:21, Simon Slavin <slav...@bigfraud.org> wrote:
>But I think the BEGIN command can be retrofitted without breaking >backward compatibility. The words WRITE and IMMEDIATE should be seen >as options. WRITE means that you want a write lock as well as a read >lock. IMMEDIATE means that you want it now, rather than when the >first command of the transaction requires a lock. Use neither, >either, or both. And EXCLUSIVE gets parsed as IMMEDIATE WRITE. Thus >existing programs continue to do the same thing they always did. BEGIN [DEFERRED] [TRANSACTION] is the current default and means defer acquiring locks until they are required. BEGIN IMMEDIATE [TRANSACTION] is currently implemented and acquires a SHARED and an INTENT lock immediately. BEGIN EXCLUSIVE [TRANSACTION] is currently implemented and acquires an EXCLUSIVE lock immediately. I believe the idea would be to permit syntax something like: BEGIN IMMEDIATE [SHARED|[UPDATE]] [TRANSACTION] which would allow the specification of the type of lock to immediately acquire, either a simple shared lock, or the shared and intent locks as is currently done. The only change would then be that BEGIN IMMEDIATE SHARED [TRANSACTION] would immediately acquire a shared lock. All else would remain unchanged. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
