Re: Create an exclusive lock on an IFS file?

On 03-Nov-2014 11:37 -0600, David Gibbs wrote:

On 11/3/2014 11:18 AM, CRPence wrote:

Currently I'm looking at using this code to make the lock.

IFSRandomAccessFile lockFile = new IFSRandomAccessFile(as400,
LOCKFILE, "rw");

IFSKey lockKey = lockFile.lock(0L, 10L);

I would think more appropriate, including the optional fourth
argument [int shareOption] for the open request, using the value of
SHARE_NONE; i.e. preventing an open by any other process\thread
irrespective that other thread properly implementing the
keyed-locking scheme.?

Assuming I understand what you are saying, I'm not especially
worried about another process trying to read or lock the LOCKFILE in
question. The chances of another application trying to use the same
file in the IFS is vanishingly slim.

Correct\understood. Use of _keyed locking_ as a semaphore is, I expect, functional only for those who would explicitly look for the flag\signal; for multiple invocations of the same application, that works quite well. Whereas use of _object locking_ as a semaphore is enforced for _everyone_ [any user or application that might try to access the object], irrespective their having possibly neglected to look in the correct place for a flag\signal before proceeding to access the object\data. Yet IIRC, that the keyed-locks are implemented as Space Location Locks (SLL), then those locks are probably less resource intensive both to obtain and maintain; probably at least, a shorter code path to obtain and release.

There may be potential benefits for using the file-lock instead. While an application can know the means to test if another invocation of that application is already active, the exclusive file _object lock_ allows any other user to inquire of the availability of the file simply by trying to /open/ the file. Otherwise, outside that application, the user would need access to that code, perhaps that code being exposed to them as a command [e.g. TSTAPPLCK]; the /user/ in that case is likely the programmer, and they might prefer a way to have access to that test outside of running the application.

Also, I am unsure of the default for the optional fifth argument
[int existenceOption] for the open request, but possibly the value
OPEN_OR_FAIL is desirable if the semaphore is implemented as a "lock
on *a known* IFS file" [emphasis mine].?

The file in question should *NOT* exist. If it does, then reason
would the application left the file behind accidentally (aborted,
killed, etc, before cleanup). I've changed my code to be the
following:

file = new IFSFile(as400, LOCKFILE_NAME);

lockFile = new IFSRandomAccessFile(file, "rw",
IFSRandomAccessFile.SHARE_ALL,
IFSRandomAccessFile.OPEN_OR_CREATE);

lockKey = lockFile.lock(0L, 10L);

(the above code is actually encapsulated in a class)

This way, once the lock is no longer needed, I perform the unlock
and then delete the lock file.

Looks good; though again, I've never used that locking [IFSKey]. IIRC there is something in iNav that expose SLLs, so if interested, visiting that feature to list those locks for a process expected to hold that lock for the application might be of interest; if nothing else, to see if\how they are presented there, if they are SLLs, as possibly beneficial for any possible future debug activity that might be related to the [un]locking.