Yes, you can do locking on a specific table.
F1 Help.
<i>
SAP Locking
To synchronize simultaneous access by several users to the same data, the R/3 System provides a further locking mechanism in addition to database locking. The SAP locking mechanism allows:
data objects which are currently being changed or read by an transaction to be protected against parallel changes being made by other transactions.
a transaction to be protected against reading data objects which have not yet been finally written by another transaction.
The essential difference between this locking mechanism and database locking lies in how long the lock is applied. While a database lock is applied until the end of an LUW, the SAP locking mechanism can be used to lock objects right up to the end of a transaction. In contrast to database locks, the SAP locks remain in place in a dialog transaction, even if the screen changes.
Example: In a flight reservation system, suppose you want to make a booking for Lufthansa flight 0400 on 16.05.1996. This is only possible if there are still enough free seats. To prevent two bookings from being made at the same time, and thus to avoid overbooking, the entry in the database table SFLIGHT corresponding to this flight must be protected against changes by other transactions. This ensures that the query about the number of free seats in the field SEATSOCC, the booking of the flight and the update of the field SEATSOCC can proceed undisturbed by other transactions.
How is locking achieved?
To be able to request an SAP lock in an ABAP program, you must first create a lock object by choosing Development -> ABAP Dictionary. A lock object contains the database tables for which you want to specify a shared lock. When you activate the lock object obj , this generates two function modules (see CALL FUNCTION) with the names ENQUEUE obj and DEQUEUE obj. These function modules perform the explicit locking or releasing of SAP locks in an ABAP program.
What is locked?
The SAP locking mechanism sets logical locks. In contrast to database locking, a transaction does not lock concrete objects, but describes those objects it wants to lock with a condition.
Example:
"Lock Lufthansa flight 0400 on 16.05.1996".
This condition is entered in a lock table. From this moment, all the objects which satisfy this condition are locked.
Because of the overhead involved, the SAP locking mechanism does not allow you the same amount of freedom when formulating lock conditions as a WHERE clause. To formulate a lock condition, you have to specify values for the primary key fields of the tables contained in the lock object. For this purpose, the function modules ENQUEUE_obj and DEQUEUE_obj have identically named IMPORT parameters.
A lock request for the lock object SFLIGHT in an ABAP program with the above lock condition has the form:
CALL FUNCTION 'ENQUEUE_ESFLIGHT'
EXPORTING MANDT = SY-MANDT
CARRID = 'LH'
CONNID = '0400'
FLDATE = '19960516'
EXCEPTIONS FOREIGN_LOCK = 1
OTHERS = 2.
Lock mode
Although one type of lock should be sufficient to control accesses to data, the SAP System recognizes two types of locks. This enables you to achieve a greater degree of parallel running among transactions. The two types are:
Read lock (shared lock)
This allows other transactions to set further read locks, but prevents write locks form being set for the locked objects.
Write lock (exclusive lock)
This does not allow other transactions to set simultaneous locks for locked objects.
How are locks set?
When calling a lock function module, you can specify the lock mode for each table tab listed in the lock object by assigning a value to the IMPORT parameter MODE_tab. A write lock is set by the value 'E' and a read lock by the value 'S'. When creating a lock object, you must specify a lock mode default value for each table.
When a lock is requested, the system checks whether it clashes with any other lock already in the lock table. A conflict between two locks exists if there could be a database object which satisfies both lock conditions with mutually exclusive lock modes. You use the parameter WAIT to determine behavior in the event of such a collision. If this parameter contains the value 'X', the system waits until the lock is granted or until an internal time limit is exceeded. In the latter case, the exception FOREIGNLOCK is triggered and the name of the user who set the conflicting lock is assigned to the ABAP/4 system field SY-MSGV1. If the parameter WAIT contains a different value, the exception FOREIGNLOCK is triggered in the event of a collision. Unlike database locking, no deadlock can occur here.
Of course, each explicit locking process assumes that all programs which perform database accesses work together in a cooperative manner. If a program does not behave in this way, i.e. it reads or changes data without locking it beforehand, this may result in a conflict with another program, even this other program has locked data correctly.
The following program fragment presents a solution to this problem:
TABLES: SFLIGHT, SBOOK.
CALL FUNCTION 'ENQUEUE_ESFLIGHT'
EXPORTING MANDT = SY-MANDT
CARRID = 'LH'
CONNID = '0400'
FLDATE = '19960516'
MODE_SFLIGHT = 'E'
EXCEPTIONS FOREIGN_LOCK = 1
OTHERS = 2.
CASE SY-SUBRC.
WHEN 1. ...
WHEN 2. ...
ENDCASE.
SELECT SINGLE * FROM SFLIGHT
WHERE
CARRID = 'LH' AND
CONNID = '0400' AND
FLDATE = '19960516'.
IF SY-SUBRC <> 0.
MESSAGE E...
ENDIF.
IF SFLIGHT-SEATSOCC < SFLIGHT-SEATSMAX.
SBOOK-CARRID = 'LH'.
SBOOK-CONNID = '0400'.
SBOOK-FLDATE = '19960516'.
...
INSERT SBOOK.
IF SY-SUBRC <> 0.
MESSAGE E...
ENDIF.
UPDATE SFLIGHT
SET
SEATSOCC = SEATSOCC + 1
WHERE
CARRID = 'LH ' AND
CONNID = '0400' AND
FLDATE = '19960516'.
ELSE.
MESSAGE E...
ENDIF.
CALL FUNCTION 'DEQUEUE_ESFLIGHT'
EXPORTING MANDT = SY-MANDT
CARRID = 'LH'
CONNID = '0400'
FLDATE = '19960516'
MODE_SFLIGHT = 'E'.
COMMIT WORK.
How long are locks retained?
In contrast to database locking, SAP locks are retained even when the screen changes in dialog transactions.
In the above example, further dialog steps follow the selection of a flight with free seats to enter additional data for the reservation. Here, the adding of the flight reservation occurs in a different LUW than the original selection of the flight. Database locking does not prevent another transaction from booking this flight in the meantime. This means that the scheduled booking may have to be cancelled after all.
But: If an object remains locked for a long time, its availability to other transactions is correspondingly reduced. Whether this can be taken into account always depends on the task at hand.
To unlock data, you call the function module DEQUEUE_obj. Here, the lock condition and the lock modes must match the specifications in the ENQUEUE call.
Normally, each lock is released at the end of the SAP transaction without calling the corresponding DEQUEUE function module. However, this does not apply if the transaction has called update routines (see Programming Transactions). In this case, you can handle locks with the _SCOPE parameter. The values of this parameter have the following meaning:
1
Lock is to be released at the end of the SAP transaction. Asynchronously executed update routines in the current transaction cannot rely on this lock.
2
Lock is to be released at the end of the transaction. Asynchronously executed update routines of the current transaction thus can rely on this lock. If the _SCOPE parameter does not contain value when the ENQUEUE function module is called, the value 2 is accepted.
3
Lock is to be released at the end of the SAP transaction. Asynchronously executed update routines of the current transaction can rely on this lock.
The SAP update concept has two priorites for function modules which run in the update task: Start immediately (V1 function modules) and Start delayed (V2 function modules). If all V1 function modules have been successfully processed, the update program deletes all ENQUEUE locks specified by the transaction. This means that the V2 function modules cannot rely on the locks set.
Further information
See Using the SAP Locking Facility
</i>
If your table doesn't already have a lock object, you can create one via SE11.
Regards,
Rich Heilman
- SAP Managed Tags:
Yea, I don't know if there is a mechanism to apply a "lock" on a file on the application server.
Regards,
Rich Heilman
- SAP Managed Tags:
Oh ok.........i see what you are doing. I think this will work. How are you calling this function module. Make sure that you are using the following parameters, this will make it that you are setting the lock for only that file.
VALUE(VOLDIR_SET) TYPE TXW_LOCK2-VOLDIR_SET OPTIONAL
VALUE(TAX_FILE) TYPE TXW_LOCK2-TAX_FILE OPTIONALRegards,
Rich Heilman
- SAP Managed Tags:
Try something like this where <path> is the path of the file and <filename> is the file name of the file that you want to lock.
call function 'ENQUEUE_E_TXW_FILE'
exporting
* MODE_TXW_LOCK2 = 'X'
voldir_set = <path>
tax_file = <filename>
* X_VOLDIR_SET = ' '
* X_TAX_FILE = ' '
* _SCOPE = '2'
* _WAIT = ' '
* _COLLECT = ' '
exceptions
foreign_lock = 1
system_failure = 2
others = 3.Regards,
RIch Heilman
- SAP Managed Tags:
Or are you talking about actual files on the application server.
Regards,
Rich Heilman
- SAP Managed Tags:
