Business Context
A junior developer attempts to use `checkInAllObjects` inside an active database transaction. According to the documentation, this is incorrect usage. The system must ignore the global check-in request while the transaction is active, ensuring data integrity is not compromised by premature unlocking.
About the Set : accessControl
Management of access rights and data security.
Discover all actions of accessControl Data Preparation
Create a financial ledger table.
Copied!
| 1 | |
| 2 | DATA casuser.ledger; |
| 3 | INPUT acct_id balance; |
| 4 | DATALINES; |
| 5 | 101 5000; |
| 6 | |
| 7 | RUN; |
| 8 |
Étapes de réalisation
1
Start a transaction, checkout an object, and incorrectly try to use checkInAllObjects.
Copied!
| 1 | PROC CAS; |
| 2 | ACCESSCONTROL.startTransaction; |
| 3 | ACCESSCONTROL.checkOutObject / uri="cas/caslibs/casuser/tables/ledger"; |
| 4 | |
| 5 | /* Incorrect usage: attempting checkInAllObjects inside a transaction */ |
| 6 | ACCESSCONTROL.checkInAllObjects; |
| 7 | |
| 8 | /* Verify lock persists because transaction is active */ |
| 9 | d = ACCESSCONTROL.whatCheckoutsExist; |
| 10 | PRINT d; |
| 11 | RUN; |
2
Commit the transaction and verify the lock is released naturally or via subsequent cleanup.
Copied!
| 1 | PROC CAS; |
| 2 | ACCESSCONTROL.commitTransaction; |
| 3 | ACCESSCONTROL.whatCheckoutsExist; |
| 4 | RUN; |
Expected Result
In Step 1, despite calling `checkInAllObjects`, the `whatCheckoutsExist` check MUST still show the 'ledger' table as checked out. The action should effectively do nothing or warn when a transaction is active.