I'm seeing a lot of records in the application locks session (ttadv9598m000).
Some are obviously hanging there and can be removed, others are clearly current, but there is a big grey area with locks that I'm not so sure off.

What are the consequences of removing an application lock that is still in use (isn't the record locked on the DB-level)?

What are the consequences of not removing an application lock that is no longer used?

Are there some general guidelines for maintaining this session?

:confused:

Here is some info-

Application Locks are not deleted when a user exits bshell or disconnects. This is creating several application locks on the functional sessions for several days. We have to now go to the application locks sessions and delete them manually after the developers advise what has to be done.

If the user exits session normally the application lock must be release by the application itself. It is possible for a session(s) that the application lock will not been deleted ( could be a programming problem ), if these is the case, please let us know in which specific session the lock is not deleted.

If for some reason the bshell is disconnected and the session will not be closed normally, there will be an application lock. The only way to release it is using session ttadv9598m000 " Remove application Locks"

If you uncomment these lines from the $BSE/etc/rc.start shell, the application locks will be removed when you start the Baan product.
#Optional Remove all Application Locks
#${BSE}/etc/rc.start_remall
You can use the same shell when no users are log on the system to delete all the Application Locks.

By using the session 'Remove range of application locks' [ttadv9298m000] you are able to remove a range of application locks. You can use this for instance in a night job after all the users have left the system and when no other programs are running. When running this program you must ensure that no locks are set. They may cause problems when running other programs in a night job.

The "exit" option located at the option dialog, is not a normal way to finish a session, the session will be terminated as a "kill" and it will not follow the program logic and the application log will not be deleted.

If you exit from Worktop, and there is an open session with an application lock, the system will display the next message: " There are sessions with an application lock that cannot be closed", then Worktop will be closed but the session will remain open until the user exits from the session, and at that moment the application lock will be released.

Application Locks Explanation:
An application lock is set in applications, where data must be locked for a long period, e.g. in the text editor. In normal situations, application locks are removed by the application, which has also set the lock. Only in case of system crashes/failures, it is possible that application locks remain in the system. In this session you can remove these application locks. Remove only the application locks, if you are sure that the application which has set the lock, is not running anymore

Thanks for your response NPRao, but I am still unclear on the situation.

What are the ramifications if an application lock is (accidently) removed while the application that set the lock is still running?

Also, what is the purpose of these locks when the records are already locked at the database level?

Baan-Anna,

Refer to - Application locks: overview (http://www.baanboard.com/programmers_manual_baanerp_help_functions_appl_application_locks_overview)

Application locks: overview
--------------------------------------------------------------------------------
Use these functions to handle application locks for 4GL processes.

You use application locks to prevent other applications and users from reading and/or modifying an application's data during critical operations. For example, to prevent access to data when it is being updated.

You can set an application lock only for the current 4GL process. You can test for or delete an application lock only within the application to which it applies.

Application lock features
Each application lock has an owner, which is automatically assigned. The owner consists of a combination of the login ID of the application user, and the process ID of the application.
Each application lock has a unique name, which you define when you create the lock.
An application lock is automatically removed when the application ends. You can also remove it with the appl.delete() function.
An application lock applies only to an application and that application's data. It is not part of the RDBMS and is not linked to a table or a particular database transaction. To set table locks, use db.lock.table().

The ramifications depends on the functionality of the sessions in use.

I hope the last bold line clears your 2nd Q.

You can also use the Search (http://www.baanboard.com/baanboard/search.php?s=) on the board here with keyword - application lock to see others problems.

Also, please review the Baan method of 'locking records'. Baan uses a 'delayed locking' mechanism. That is, the record updates are 'qued' so to speak, until a commit transaction is issued. This can create the situation of 'dirty reads'. This happens when the logic reads a record say, 5 seconds ago, changes some values, then does an update. When the commit is issued, it is VERY possible that a change has been made to the record, through some other process. This generates a 'db.retry', and the whole process it tried again. This problem has to then be handled programatically - lots of more complex discussions on that.

The application locks are out there as an attempt to stop this. You cannot modify an hours accounting record, for instance, if someone else is already modifying that. The database really doesn't care - it will process 1 on top of the other, or return a dirty ready error, but the programmer knows this would not be good, so uses an application lock in that instance. Same is true for large processes, if 2 people start a large process, they may both select the data, but 1 performs the commitsd before the other, and the 2nd one is ...basically hosed or acting unpredictably unless you write complex db.retry logic, which is not done much. That's why the large process also have application locks.

Thanks guys!!