EnterpriseManager and GetForUpdate action

EnterpriseManager and GetForUpdate action

EnterpriseManager: Just wondering how come outsystemsEnterpriseManager: Just wondering how come outsystems did not use "GetforUpdate" Action, when updating a record? (Outsystems developers did not like the idea of locking the record before updating?)

I'm trying to understand the reason for outsystems developers choosing not to use "GetforUpdate" Action, before updating a record?
(did not like the idea of locking the record before updating it?)
There is only 1 time that the "GetForUpdate" action is used in EnterpriseManager eSpace, and that is under  "AdminFlow\Cfg_Locales\SetActive" (GetForUpdateLOCALE)

The only time outsystems developers used "GetForUpdate" action is  did not use "GetforUpdate" Action, when updating a record? (Outsystems developers did not like the idea of locking the record before updating?)
The only time outsystems developers used "GetForUpdate" action is 
Hi Robert,

I totally agree with you not understanding the 'lack' of record locking.

I'm currently using the GetForUpdate moastly for functions that update the status of a record.

In our company concurrency and correct transaction handling is very important.
(Working on a single record in a short time period, executed by multiple users is pretty common to us)

Inconsistent analysis, uncommitted dependencies (dirty read) can be a major pain and locking simply guarantees data consistency.

Powerbuilder has a good way of handling record changing without locking but with data consistency at the moment up updating.
This is a good way of eliminating blind writes.
They include the whole dataset of the original record in the where clause when updating a record.

UPDATE client
SET client_name = "Jan Peter Balkenende"
AND id = 30
AND client_name = "Femke Halsema"
AND client_city= "Haarlem"
AND client_telephone="020-123456789"
AND client_twitter_account = "@FemkeHalsema";

The main issue with that structure remains "uncommitted dependencies / inconsistent analysis" though.
Not trying to go against outsystems developer’s decisions, but rather trying to understand the reason not to lock a record before updating it. There might be valid reasons that i might not know about?

Locking the database record might be a good idea to prevent data corruption or invalidated record entries that are written to the database, especially in a multiple user application. 

What do you think? 
I think data corruption can occur in the current situation if there is only one Getforupdate.
Hi Robert and Eric,

We chose to use dirty reads and avoid explicit update locks basically to avoid scalability problems when reading data.

To avoid problems with data corruption we have added the "Update Behavior" property for Entities in 5.0. It changes all update behavior of a specific entity to ensure only effectively modified attributes are updated in the database. You have a very good description of this behavior in the What's new in 5.0 videos.

Still, if you need a strict consistency in your applications when updating or reading data, I propose you use the GetForUpdate directly, and assume the scalability penalty.

Hi Lucio,

Thanks for the clear answer.
We have some situations in which an 'atomic transaction' is needed and the records
must be changed by one transaction only; we will use the GetForUpdate in those situations.
(Those are moastly actions that transfer Finance / Stock)

Changing the concurrency level to disable dirty reads; is this to be done at database (/catalog) level or can this be set somewhere in Service Center / The platform server?
(Youtube is Blocked by our Sysadmins, so I can't see the Video)

Thanks for the video, I can see how the new "Change Behavior" has corrected the issue! 

Makes sense, .....you might also want to replace "GetForUpdateLOCALE" under EnterpriseManager: "AdminFlow\Cfg_Locales\SetActive".

Hi Eric,

I'm not aware of any external way to define the transaction isolation level of the platform.

What is the correct transaction isolation level that you are looking for? Do you really want to make it the default? Wouldn't it be more interesting to define a locking mechanim for specific entities and leave the system as fast as possible by default?

Hi Lucio,

I would expect either READ COMMITTED or SERIALIZABLE to be a default isolation level.

Indeed this would be needed only for a selective number of tables or table combinations or even a selective number of columns.
It would be very nice if a read committed isolation level could be set from the IDE. (Service Studio)

Usually the transaction isolation level is determined by the DBMS; check the wiki site below for more info.
I'm wondering what the reaction of the platform will be in case of a uncommitted dependencies and inconsistent analysis situation.
I expect that this situation isn't detected.

In our business stock moves from one client to the other and several types of financial calculations are executed.
Those calculations need a very strict isolation level that will have serializable results.

There are different ways of updating the database e.g.:
Conventional budget value update method using both
a simple query for a select and for an update

SELECT budget
FROM client
WHERE client = "me";
as from here there is an opening for an inconsistent analysis

newbudget = budget + increaseamount

UPDATE client
SET budget = @newbudget
WHERE client = "me";

Move of the "increase" to the database using an advanced query
UPDATE client
SET budget = budget + @increaseamount
WHERE client = "me";
The database will take care of that above situation will be executed as one atomic transaction.

Another structure could be used, but is not preferred; instead of updating a 'budget' the budget
could be determined on a grouped combination of ALL records in a table with the same where clause.
This has as a negative result that the "budget" value needs to be (re)calculated everytime it is displayed
and no updates are te be executed on the table; only inserts.

Hi Eric.

It makes sense to have a default transaction isolation level behavior per entity. In my opinion it should be specified per entity. I suggest you add the idea to the Wisdom of the crowds to pressure product management.