Morning all!

On several mornings over the last month, had to reboot our FMS 19 server after it got bogged down in some locking conflicts. My investigation has concluded the following, with 90% certainty ...

First lock record in TopCallStats is on a table that is never edited. It's a history table where we store audit records. The script called simply creates a new record, sets a half dozen fields, commits the record, and goes on it's way. TCS log shows "Commit Records (Lock Conflict)". Soon other functions are tangled up because of it and it just snowballs until the system becomes unusable. The system won't let go of the commit. That function is performed on an IPAD running FMGo.

In latest case, the next log record, performed at same TS, is (Download With Lock (Lock Conflict)), by another FMGo client, on the same table. It seems the Download With Lock (Lock Conflict) issue occurs directly after the Commit Lock in many cases.

I assume that this lock is not the source of my issue, that a function that occurred previous to it caused the commit lock when saving the record. My big question though is why would a NEW record be locked when attempting to commit? My understanding is that you can lock a record in edit, but would it lock the whole table? Which leads to me to the thought that would an auto enter calc field in that table get caught up in a locked record in it's target table that would lock the save commit? Currently I only have one auto enter calc in that table, which just captures the sum of a number field in a child table.

Thanks for any wisdom on this ... it's wildly disruptive to have to reboot the box, lots of FMP and web connections and sad people.

 

There is a documented change in behavior of commit is 19.5. Previously, if a user allowed a record that failed validation to be saved, then that records validation wasn’t challenged again. That has changed. Perhaps your issue is related? 
 

https://community.claris.com/en/s/question/0D53w00005nfiLRCAY/claris-inc-changed-how-validation-existing-value-works

Thanks for your response! We don't have any validation on those fields (except for the PK serial). But will investigate these changes further since this really did start after we migrated up to 19 ... thanks for the heads up.

Confirm you don’t have duplicate primary keys.