![]() The registered locks remain in the lock container. ![]() In this case, none of the registered lock requests is executed. If one of the locks in a container cannot be set, the function module FLUSH_ENQUEUE triggers the exception FOREIGN_LOCK. ![]() When the lock orders of a lock container can be executed, the lock container is deleted. The lock container can be terminated using the FLUSH_ENQUEUE function module and sent to lock administration. The data transferred via the lock module interface is then registered in a list (lock container) as a lock request that needs to be executed. For this purpose, qualify the IMPORT parameter_collect with 'X'. The locks (delayed execution) can be collected when the lock modules are called. To do so, collect the required lock requests of your program and send them together to lock administration. If your program sets locks for several objects, this interval occurs more than once.īy using so-called local lock containers, you can reduce these communication intervals with lock administration. The Communication step requires a certain time interval. Requesting a lock from a program is a communication step with lock administration. For this reason, you should always follow the recommended procedure. This means that a user of your program will make decisions for entries that are not based on up-to-date data from the database. Your program can read data before another user's program writes changes to the database. Lock -> Change -> Unlock, you run the risk that the data read by your program will not be up to date.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |