From b99af0b47d0e733340c54cbe9788458f70e8fe50 Mon Sep 17 00:00:00 2001 From: KilianCroese Date: Fri, 27 Oct 2023 12:11:53 +0200 Subject: [PATCH] Changed pessimistic to optimistic --- src/data/concurrent-updates/faq.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/data/concurrent-updates/faq.md b/src/data/concurrent-updates/faq.md index da76a574..fdf8c031 100644 --- a/src/data/concurrent-updates/faq.md +++ b/src/data/concurrent-updates/faq.md @@ -1,6 +1,6 @@ --- tags: support-Database -summary: Learn how to manage concurrent updates on application data records using a pessimistic concurrency strategy, audit attributes, and a force update option. +summary: Learn how to manage concurrent updates on application data records using a optimistic concurrency strategy, audit attributes, and a force update option. guid: c5dedbf3-215c-4934-b4ef-fccf90e989e7 locale: en-us app_type: traditional web apps, mobile apps, reactive web apps @@ -15,7 +15,7 @@ How should we handle concurrent updates to avoid users smashing each other updat ## Answer -In this article we’re going to see how we can deal with this challenge, implementing a **pessimistic concurrency strategy**, trying to detect update conflicts on the saving of the record and allow the user to act up on them. +In this article we’re going to see how we can deal with this challenge, implementing a **optimistic concurrency strategy**, trying to detect update conflicts on the saving of the record and allow the user to act up on them. To prevent other transactions from accessing a record, OutSystems entities have a **GetForUpdate** action that allows to lock the record while it’s being updated. This will handle concurrency, but you still need to deal with the conflicts on record updates, as a user is still able to overwrite a record without knowing it has been updated by another use.