Concurrent update the record
Application Type

In the documentation,  the Get<Entity>ForUpdate entity action can lock the records for being updated / deleted by other until the transaction is completed.  However, It doesn't work as design in my reactive web app. Please advise.

In my reactive web app, i placed the Get<Entity>ForUpdate entity action in the client action for locking the record. Unfortunately, other users still can update the record without warning or hanging. Does this action not works in the client action?

Thank in advance

Hello Jessica,

As per my understanding, Client action is client processing so i guess record does not lock as expected.

If you want to achieve the locking, create a server action wrapper that will help to achieve your target.



Thank Krunal.

It is so weird that this action is allowable to use but not functionable in the client action. May i know how to identify the action to be used in client or server action properly? Please advise.

Hello Jessica

I am not sure if dedicated document is there on which action should be used where but I believe you must receive the Security Warning in TrueChange. 

Through those warning you can keep the application in best practices at runtime. 

Hello Jessica,

I also find it bit weird, I am not expert though.

Would like to hear from an expert about the unexpected behavior.

And usually server action rather them using directly inside a client action are wrapped using service action and used inside a client action.



Thank all.

Hope other experts to give their ideas or experience. 

I am little bit confused about this entity action. 

Also, should other entity actions be used in the server action except get<Entity>?

Hi Jessica,

I am not sure if you have already gone through with this link. If not please try this.

Thanks & Kind Regards,


Thank Sachin.

I have read this documentation before. Unfortunately, it doesn’t give me the answer. May you advise me?

Hi Jessica, 

with this action you are able to lock a record during a certain transaction.

When you want to realize something that will set a lock on a record using a client action, than there must be logic to determine when a lock has been released, and if there is any timeout, you should have a fallback mechanism to release the lock. So you'll have to be careful to implement such an locking mechanism and know the pitfalls. 

Besides that, the general advice is to expose entities as read only. For your personal purposes and trainings it is ok to use them directly, but not for real applications.

Can you explain a bit more when and why you want a locking mechanism?
regards, Hans 

Thank Hans.

In my application, user may open same page twice and accept them. It will cause my application to generate duplicated payment charge incorrectly. Hence, I want to implement the concurrent lock mechanisms. Any advices?

Hi Jessica, 

In that case, you might use the solution Sachin provides .

and just lock it at server action level instead of client action level. 

When a payment charge already has a certain status, you'll just throw an exception. 

regard Hans

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.