Understanding MvLOCKFILE

[wcw]

Can anyone explain the use of MvLOCKFILE?

When looking at 4.13 source code I came across this in the authorize payment function:
<MvLOCKFILE FILE = "{ g.MerchantPath $ BasketList.d.session_id }">
Then there are several lines of code including converting the basket to an order and running all of the fulfillment modules (e.g. emails, etc). Then there is a </MvLOCKFILE> command.

It appears it is creating a file with this user's session_ID as the name of the file. So is it only locking processes for this specific user? Thus other customers shopping in merchant simultaneously don't have any files locked. Is that right? Or is everybody locked? Also, what files are locked? What purpose does it have if the files are not locked from other users updating files? Is MvEXPORT effected by the MvLOCKFILE command or is it only for databases?

The reference manual does not shed any light on this:
<MvLOCKFILE>

FILE="filename"

. Empty tag.
. Indicates to other processes that the current process has requested an exclusive lock on FILE.
. Multiple lock requests are queued.
. <MvLOCKFILE> tags can be nested.

[Dramatic]

<MvLOCKFILE> prevents any other Miva Process from writing to the locked file until the </MvLOCKFILE> tag is processed* PROVIDED the other process is also using MvLOCKFILE.
(In other words, if you have two scripts, only one of which has an MvLOCKFILE around its writes, there is no protection. The operation might be described as "Check if the file is locked by any process: If it is, idle until file is unlocked then lock the file and continue:If it isn't, lock the file and continue.) Locking is achieved by writing/erasing another small flag file.

In this instance, it looks as though the file being locked is specific to one customer. That would provide protection against double-submits or the customer refreshing the page (both of which can wipe order data in a process which migrates data from one location to another if there is no specific protection against them)

*If a miva script terminates due to a fatal error or timeout, the processor is supposed to release any file locks.

[Dramatic]

oh, and yes it covers MvEXPORT too. In fact you need it more for MvEXPORT. Writes to database records use automatic record-level locking to prevent two processes updating the same record simultaneously.
The main reason to use lockflie on database writes is to protect MvREINDEX and MvPACK operations.

[wcw]

So is the file being locked the one that is listed in this tag?
<MvLOCKFILE FILE = "{ g.MerchantPath $ BasketList.d.session_id }">
or is that the small flag file? I wasn't aware a file named for the session_id even existed. That would result in thousands of unique session_id named files. This is why the source code example did not make sense.

If I want to write order data to a flat file called basket.dat and two orders are completing at once, how do I use the MvLOCKFILE to write the first order and put the second in idle until the first is done? I'm using file_append and using the error code return of -1 to keep trying until successful. Rather clumsy. Then again, I can see where lock files might not get unlocked and cause problems.

[Dramatic]

yes, the file named is locked (the name of the flag file is based upon it). I'm not familiar with Merchant, but maybe it cleans up these session files at some point.

For your question, you would use lockfile every time you write to that dat file. Nothing else is necessary, except possibly a timeout handler. If Miva was leaving dead flag files around, I'm sure it would have been reported by now. Only the mva devs could tell you how that is managed.

I recall a number of threads about the details of lockfile on the old miva-coders mailing list, and it might be worth searching the archives of that.

[wcw]

It seems to be working. Thanks for the insight.