Handling Locking...

[tesneddon]

I recently found out, via this Twitter message:

that this SQLite3 port had made it into the latest Python. Given someone is actually looking at it I have begun to investigate a proper solution to the SYSLCK privilege issue and was hoping that @hb-- might be able to provide some input.

At this point I was thinking of using $SETPRV to try enabling SYSLCK and based on the return status create a system-wide lock or not. However, what I don't like is that this would fail silently if system-wide locking was wanted, but there was insufficient privs.

Another thought was a logical that specified which type of lock to use.

There was a HAVE_SYSLCK patch submitted by @hb--, but my only disagreement with this is that the library has to be recompiled. I would like to provide binary install kits as well as source.

[hb--]

Me? My opinion? I have some ideas but admit they are not yet thought through.

I don't really like feature logicals, I prefer a command line option or a configuration/initialization setting. As far as I can see there is nothing on the command line, in the meta commands or the settings which uses/sets/reads OS specific settings. And I have no idea how difficult it would be to create such a ".vms_syslck ON|OFF - Use system wide locking (default ON), requires the syslck privilege." (with the corresponding parsing of the setting vms_syslck = ON in the initialization file, for example .sqliterc). And, whether that would work without the main image.

Another thought would be to require the main image to be installed with SYSLCK (and the shareable image just being installed) to get system wide locking. Then the approach based on the return code should work. That would require other images which use only the shareable to be installed with SYSLCK as well. I don't know whether that is an option. Also I don't know how Python is using sqlite3 but I suspect only the shareable image is activated via lib$fis.

Are there OS and/or VMS specific initialization routines? Any such init routine should be able to check whether the process runs with SYSLCK or not and based on that use system wide locking or not.

To me a switch or setting seems the best approach. Then the user can decide - independent of the privileges - whether system wide locking should be used or not.

[tesneddon]

Yes @hb--, you :-).

Your comments really echo my own thoughts. I think that a directive (like .vms_syslck is probably the best way to go). That said, I was just having a look through the SQLite documentation again and I noticed that there is mention of a way for VFS implementations to support their own pragmas. I don't remember ever seeing it before, so maybe it is new or I'm miss reading it. I will look it up and see if it is anything useful. The PRAGMA documentation is here:

http://sqlite.org/pragma.html

[tesneddon]

After reading the details of the xFileControl and SQLITE_FCNTL_PRAGMA documentation I have decided that it would be best to implement a locking_scope pragma. The syntax would be something like:

PRAGMA locking_scope = system | process (D)

The default mode is to use the process scope, allowing a user to switch to system/cluster-wide locking.