Hierarchy
SAP_BW (Software Component) SAP Business Warehouse⤷
BW-PLA (Application Component) Planning⤷
RSPLS (Package) Planning: General Services
Basic Data
| Data Element | RSPLS_LOCK_METH |
| Short Description | Planning: Lock Method |
Data Type
| Category of Dictionary Type | Direct Type Entry | |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | ||
| Data Type | CHAR | Character String |
| Length | 3 | |
| Decimal Places | 0 | |
| Output Length | 3 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | Lock |
| Medium | 20 | Lock Method |
| Long | 40 | Lock Method |
| Heading | 50 | Lock Method |
Documentation
Definition
If transaction data is requested in change mode, this data has to be locked exclusively for one user. The data records that need to be locked are described in a selection table. A data record is locked by the selection table if for each characteristic in the selection table, the characteristic value in the data record lies within the selection. If the selection table is empty, each data record is locked. In this case it is irrelevant whether the data record exists in the database.
These selection tables have to be stored and managed centrally for all users and application servers. The SAP Standard Lock Server cannot manages locks that are based on selection tables. For this reason, you have to make your own settings for storing locks that are described by selection tables.
Use
You have the following options for storing lock tables:
- The selection tables are compressed and stored on the SAP standard lock server. The collision check for locks is not performed by the lock server, but by an ABAP program. This check requires that the selection tables are copied to the user context. If you choose this option, the system performs a collision check by default on the server on which you are logged on. However, you can also set a fixed server for this. The collision check is performed on the specified server using an RFC call. This setting is useful if the enqueue process is not installed on the central instance but is installed instead on a different server that may be faster. Copying the selections from the lock tables to the user context takes less time on this server. The system indicates which server the enqueue process is installed on. If you use the standalone enqueue server, the lock table is saved in the SAP standalone enqueue server by default. For more information on this topic, see Note 1016594.
- The selection tables are not compressed. They are stored in a shared object memory area. This shared memory area is connected to an application server. In this case, the SAP standard lock server only contains a 'pointer' to the selection (one lock record for each selection table). If you choose this option, you have to specify the server on which you want to save the lock table in the shared object memory. The default setting is the server with the enqueue process. This server is also used for the collision check. Therefore it is not necessary to copy the selections from the lock table to the user context. If the user is logged on to a different server, the collision check is performed using an RFC call. Here too it may be useful to install the enqueue process on a separate (faster) server rather than on the central instance. During a lock process, the selections in the shared object memory are synchronized with the 'pointers' on the SAP lock server. This is easier if only one server is involved.
Dependencies
The default setting is option 2. For information about sizing for the BW lock server, see SAP Note 928044.
- Option 1 requires the least administrative effort. It is suitable for small and mid-size installations. You can set the size of the lock table using the profile parameter enque/table_size.
- Option 2 offers better performance than option 1. However, here you have to ensure that the server that has the lock table is always available when you want to lock transaction data using selections. You can set the size of the shared object memory using profile parameter abap/shared_objects_size_MB.
The time needed to set a lock can be anywhere between a few milliseconds and half a second. The length of time depends on the complexity of the selection und lock request and the total number of locks set by all users for each InfoProvider. You can reduce the load on the lock server by reducing the number of lock-relevant characteristics. You can maintain the relevant settings on the second tab page in this transaction. Here you will find an example of which characteristics should be lock-relevant and which should not.
Example
History
| Last changed by/on | SAP | 20130604 |
| SAP Release Created in | 400 |
