concurrency-locker-extension
Web icon

Synchronization Lock Extension

Stable version 1.0.1 (Compatible with OutSystems 11)
Uploaded
 on 25 April 2020
 by 
0.0
 (0 ratings)
concurrency-locker-extension

Synchronization Lock Extension

Details
All the tools included to explicitly lock and unlock objects for use. Helps to solve some concurrency issues where users are working from the same task pool. Can be used as a "check in/Check out" for your objects too. Your choice of how to use it. If you have no single AO to spare and you are only running a single front end server, you can get away with using only the dictionary methods in the extension, Locks will persist in memory for as long as the server is not restarted or app re-published. Limitations of the dictionary functionality: The Locks will not be pervasive between e-space modules i.e. module (A) will not know about locks created in module (B) even if module (A) and (B) share the same data entities and exist in the same application. Locks will not be pervasive between front end servers because each server will have it's own instance of the dictionary in memory. Use the Persistent methods if you wish to populate a table with your lock entries. Supports exactly the same functionality of the dictionary, except you will have none of the limitations. Locks are persistent between applications and since there is only one source of data, all of your front end servers will know about the locks. In this demo, I have combined the dictionary and persistent methods into the "Entity" methods (yes, this is massive overkill). The Persistent locks act as the master (single) source of data and the "IsEntityLocked" method re-synchronizes the dictionary and the persistent locks. If only an entry is found in the dictionary, then that entry is removed. If only and entry is found in the table, then a dictionary entry is created. Use the object listing screen and the view locks screen to see how this works.
Read more

Demo user names: Jim, Tommy. Password 1234.
In this demo, A user explicitly locks the printer object. The second user logs in and tries to change the printer object. An Error is thrown because the object is locked. 

Depending on your desired use case, this can easily be changed so that when User (A) opens the detail screen, the object is automatically locked, and when he saves or cancels, the object is automatically unlocked. You could also check for a lock when User (B) tries to get to the edit screen and simply throw the error and redirect User (B) back to the list.

If you have a particularly long and intricate save method for your object with lots of other actions, you could lock the object at the beginning of your save and unlock when save completes. This will prevent any other user from also running the save function at the same time. If you wish to use it this way, a good practice to follow would be to unlock your object again in the exception flow. 

Most importantly, remember to always use the same unique identifier for the same object. I.e. always generate your unique identifier the same way.

Release notes (1.0.1)

All the tools included to explicitly lock and unlock objects for use. Helps to solve some concurrency issues where users are working from the same task pool. Can be used as a "check in/Check out" for your objects too. 

Your choice of how to use it. If you have no single AO to spare and you are only running a single front end server, you can get away with using only the dictionary methods in the extension, Locks will persist in memory for as long as the server is not restarted or app re-published. Limitations of the dictionary functionality: The Locks will not be pervasive between e-space modules i.e. module (A) will not know about locks created in module (B) even if module (A) and (B) share the same data entities and exist in the same application. Locks will not be pervasive between front end servers because each server will have it's own instance of the dictionary in memory. 

Use the Persistent methods if you wish to populate a table with your lock entries. Supports exactly the same functionality of the dictionary, except you will have none of the limitations. Locks are persistent between applications and since there is only one source of data, all of your front end servers will know about the locks.

In this demo, I have combined the dictionary and persistent methods into the "Entity" methods (yes, this is possibly massive overkill). The Persistent locks act as the master (single) source of data and the "IsEntityLocked" method re-synchronizes the dictionary and the persistent locks. If only an entry is found in the dictionary, then that entry is removed. If only and entry is found in the table, then a dictionary entry is created. Use object listing screen and the view locks screen to see how this works.

Reviews (0)
Team
Other assets in this category