[Solved] Question about record locking and one user overriding another’s data

I fixed the problem via coding. I dont see any automatic solution to record locking.
Case closed.


I have an application that allows end users to click in a table row to select it and assign or unassign themselves to two text fields. Everything works perfectly. However, If two people do this function at the same time, one overrides the other’s changes. Here’s the processing…
The table looks something like this:

User 1 User 2 Date Start End

Joe Blow mm/dd/yyyyy hh:mm hh:mm…

mm/dd/yyyyy hh:mm hh:mm…,


[ Save ]

A user clicks on a row, say row 1 above to assign himself to the cell in the first row. The code inserts the current user’s name in the User 1 column in row 1 and then writes the row back to the collection using this code:

let rowData = {
_id: row_id,
title: rowtitle,
user1: rowuser1,
user2: rowuser2,

};
$w(“#table1”).updateRow(workrow, rowData);
wixData.save(“Schedule”, rowData) // update the row in the underlying collection
.then((results) => {
let item = results; //see item below
$w(“#text30”).text = message + “on " + rowdate
}) // Error
.catch((err) => {
let errorMsg = err;
$w(”#text30").text = ("update error: " + errorMsg)
console.log("save filed: " + errorMsg)
});

If a user selects a row, Presses “Save” his name replaces User 1. If at the same time, another user is looking at that same row and sees it is , after selecting it, his name overwrites the other user’s name when he presses save.

Question: Should Wix use the record’s underling update time to sense that user 1 changed the row before user 2 tries to change the same row, knowing that the update has been changed prior to user 2 pressing “Save”, thus raising an error condition indicating that “another user has changed this same record” or something like that.

Or do you have to code your own record locking strategy? Please advise. Obviously, having to code a concurrent update strategy to manage changes to the underlying database adds orders of complexity to the coding. It would seem that the updateRow action should manage the timestamps and trigger an error if the row’s timestamps changes between updates. Thanks.

Did you get any response to this? I have a similar requirement. I’ve tried to use the Before Insert hook on the collection, but I’ve still managed to run a test where both threads pass the before Insert checks and I end up with duplicate entries. Is the Before Insert Hooks single or multi-threaded? I assume the latter because I did end up with duplicates. Nor can I see any way of putting uniqueness constraints on a field.

Anyone with experience of this problem, and if so, how did they get round it.

No I didn’t get a response to this. I solved my problem by adding a field to the collection to store an update count. Before updating, you get the update count. Do your processing. Then, before writing the record, check the update count to see if it has changed. If it did, issue an error message stating that the record was changed by another user. If not, update the record and the record count. This works fine for my application. I hope this helps.

Phil

@phildijoseph If I understand your solution correctly, the update count is a field which is read when row is retrieved and when writing the row back, update count is read again and if not different from first update count, row is written with update count raised by 1.
If so, there is a freak possibility that in between that second read (=the check) and the write, another user, who got the same info as you, updates the row in between the 2 moments of reading/checking and raising-writing.
It´s a millisecond problem, but it does exist, and in high volume environments could lead to a problem.
In Wix´s current environment problem cannot be solved entirely, for the underlying db does not support locking natively (well, in it´s latest version it does, but not supported by Wix yet).
Did I understand your solution correctly?

Yes you understand it correctly. My app is a low volume app where the user base is small and it is certainly not mission critical (dealing with money, healthcare, inventory control, scheduling, etc.).

If you have a robust base of concurrent users hammering it constantly then it is possible that a conflict could arise. I could easily create an overwrite situation before I implemented the count. But I couldn’t break it after. I was just playing with wix to see what it could do and I have not implemented my app. It gives me pause that wix has not offered a solution for this and other necessary stuff. I am a retired software engineer and didnt get too involved in web based stuff. Did a ton of IBM and Honeywell (yes i am an old dude) assembly language, cobol, fortran, RPG and other legacy stuff creating system software, operating systems and utility programs. Now I am just fooling around dusting off my brain cells. Good luck. :grin:

“It gives me pause that wix has not offered a solution for this and other necessary stuff.”
This has been mentioned before. As Wix stated on this very Forum, it uses MongoDb, a document-based DB, not relational. So currently we do not have (pessimistic) locking, transactions (ACID), free indexing, auto-increment and other stuff right out of the box. For some type of (critical) apps, this is a drawback. Have fun dusting.

Agree. Wix is a great tool for document based content and many other traditional websites. It can’t be all things to all people… nothing can. I would recommend it to anyone who wants a powerful, easy to use and intuitive development tool that requires little programming. Hard to believe how versitile and easy to use it is. And it keeps getting better. I was using it like an access front end with backend sql server database doing data entry transactions for concurrent users. This was my first learning experience with wix. I know not to do that again. Still, it did what I needed it to do. I am impressed with wix. Phil.

Phil,
Sounds like we have had a similar career path. I touched my first IBM in 1969, so have seen off most IT scenarios and fads. Now, I’m out of retirement helping my bowling club with its web site, so hardly mission critical stuff. I did some experiments on this, and found that the current set up using the Before Insert hooks is ok for the majority of cases. (To be fair to Wix, I went back to the boilerplate code they provide with the Hooks and it does clearly state that duplicates are possible). I reckon, there is only a problem if the concurrent inserts are within a second or so of each other. So, I’ve accepted the position (Didn’t know Wix used MongoDB, hence no chance) and I’ve added a back end cron job to check for duplicates and to initiate a manual process if it detects one. We had 7 initial cases, when I hadn’t coded for the occurrence, but haven’t had any since. Guess my users aren’t generating that large a volume of traffic. Enjoy your retirement. Thanks for the initial response.