How is record locking handled in FileMaker Pro 12

[Lisa M.]

Hi,

 

 I’m curious how record locking is handled in FileMaker 12 (optimistic concurrency or pessimistic concurrency)

 

thus i can put it in my help documentation

 

thanks again for the help

[Steve Martino]

Their documentation doesn't use those terms, but it's pessimistic.  Also make sure you understand transactions when developing.

 

[Lisa M.]

I really appreciate your help 🙂 thanks!

 

Edit: here's the little blurb I placed in my help file about record locking:

 

"

If you are using this product  in a networked environment via either FileMaker Pro, FileMaker Advanced, or FileMaker Server; many people can be looking at the same data at the same time, but only one person can be actively making changes.  This is not a bug of our product or the FileMaker platform, this is a feature called Record Locking; and its purpose is to ensure data integrity.  The FileMaker database platform uses what's called a pessimistic concurrency model meaning that once a user has begun to edit a record, that user has exclusive control of that record and no one else can edit it until the first person commits the record; however, many people can view the record.  Find below an example of how pessimistic concurrency works:

Background: Let's say that we were working at a bank and a customer (let's call him John for the sake of example) and his wife (let's call her Susan for example) were both at separate teller windows trying to make changes to the same joint account (in this case let's say moving $20 from the joint account to their personal account).  Before either of them get to the teller window, the account has say $100.

Scenario 1 (Pessimistic Locking): John is called up first and asks for the balance of the joint account ($100) then he decides he wants to move $20 to his personal account.  The teller makes the transaction.  In the meantime, Susan is also called up to speak to the next available teller and says that she wants to make the same transaction; however, the teller helping Susan cannot make the change until the teller helping John commits their changes.  All the teller helping Susan can do is just look at the current state of the account.

Scenario 2 (Optimistic Locking): Let's use the same example and the same events as above; but this time, assume that the teller helping Susan can make the requested change before the Teller helping John has a chance to commit the record: the teller helping Susan would commit first and the teller helping John might lose their data depending on how the particular database is set up.

Scenario 3 (No Locking): Let's assume that all of the scenario and background was the same from scenario 1 but this time John makes his transfer and the teller does not commit thus the balance is still showing $100), Susan's teller makes her transfer (the account shows a balance of $100 when it should show a balance of $80).

At the end of the day, record locking no matter what form it takes is designed to prevent two or more users from being in the same place at the same time making changes on the same record.  Think of it like a runway; only one plane can be on the runway at any given time (all of us can watch as the one plane takes off, but there will only ever be only one plane on that runway at any given time)."

Edited June 9, 2023 by Carly F.
added snippet from my help documentation and corrected spelling errors