Concurrent access control method, system and electronic device

Abstract

This disclosure provides a concurrent access control method, system, and electronic device. The method includes: responding to a user's request to access a data object in an application software system, obtaining the user's declared operation intent and user role; based on the operation intent, user role, and business status of the data object, assigning a corresponding lock to the user from a variety of preset lock types, wherein the lock types include at least a read lock that allows multiple read operations to coexist, a write lock that allows write operations, and an approval lock that allows approval operations, with read locks and write locks coexisting and write locks being mutually exclusive; determining the user's operation permissions for the data object based on the lock type; and automatically triggering the release or conversion of the assigned lock when the business status of the data object changes due to the user's operation within the operation permissions.

Description

Technical Field

[0001] This disclosure relates to the field of data access, specifically to a concurrent access control method, system, and electronic device. Background Technology

[0002] With the development of enterprise informatization, application software systems have evolved from stand-alone architectures to networked architectures with multiple workstations sharing data, achieving centralized data management, shared computing resources, and flexible access from multiple terminals. However, this has also introduced the problem of multi-user concurrent access conflicts that do not exist in stand-alone systems.

[0003] Existing concurrent access control schemes typically employ a single-machine desktop architecture or exclusive locking, but both have the following shortcomings. First, in a single-machine architecture, data is scattered across workstations, making real-time sharing and collaboration of the same data by multiple users impossible. Second, exclusive locks are too coarse-grained, locking the entire data object or its parent aggregation unit. When one user is editing, other users cannot access it at all, and there is a lack of read-write separation mechanisms, failing to distinguish between read and write operations, leading to unnecessary access blocking. Third, there is a lack of lock lifecycle management; locks remain in use when a user is abnormally offline or forgets to close them, blocking subsequent workflows. Finally, there is a lack of integration with business approval processes; the locking mechanism and business status are independent, failing to automatically adjust operation permissions based on the business stage of the data object. Summary of the Invention

[0004] (a) Technical problems to be solved

[0005] In view of the above problems, this disclosure provides a concurrent access control method, system and electronic device to at least partially solve the technical problems of excessively coarse lock granularity, lack of read-write separation, lack of lifecycle management and lack of linkage with business approval processes in existing multi-user concurrent access scenarios.

[0006] (II) Technical Solution

[0007] This disclosure provides a concurrent access control method, comprising: responding to a user's request to access a data object in an application software system, obtaining the user's declared operation intent and user role; based on the operation intent, user role, and business status of the data object, assigning a corresponding lock to the user from a variety of preset lock types, wherein the lock types include at least a read lock that allows multiple read operations to coexist, a write lock that allows write operations, and an approval lock that allows approval operations, wherein read locks and write locks can coexist, and write locks and approval locks are mutually exclusive; determining the user's operation permissions on the data object based on the lock type; and automatically triggering the release or conversion of the assigned lock when the business status of the data object changes due to the user's operation within the operation permissions.

[0008] According to embodiments of this disclosure, the method further includes: constructing a dependency chain representing the dependencies between data objects; in response to a change event of an upstream data object, determining the downstream data object affected by the change event based on the dependency chain; and executing a processing strategy corresponding to the current business state of the downstream data object.

[0009] According to embodiments of this disclosure, a processing strategy corresponding to the business status is executed, including: when a downstream data object is in an editable state, marking its associated dependent data as expired and issuing a prompt message to the user; when a downstream data object is in a pending approval state, automatically reverting its business status to the editable state and releasing the allocated lock corresponding to the pending approval state; when a downstream data object is in a confirmed state, keeping its business status unchanged and adding a data expiration warning label to the operation interface of the application software system.

[0010] According to embodiments of this disclosure, the method further includes: when a user holds a read lock to access a data object, in response to an upgrade request issued by the user, if it is determined that the read lock meets preset upgrade conditions, the read lock is upgraded to a write lock; or when a user holds a write lock, in response to a downgrade request issued by the user, the write lock is downgraded to a read lock.

[0011] According to embodiments of this disclosure, when the business state of a data object changes due to a user's operation within their operating permissions, the release or conversion of the allocated lock is automatically triggered, including: in response to a first user triggering a submit operation on the data object, releasing the write lock held by the first user, changing the business state of the data object from an editable state to a pending approval state, and allocating a read lock to the first user; in response to a second user triggering an approval operation during approval, releasing the approval lock held by the second user, changing the business state of the data object from a pending approval state to a confirmed state, and allowing only read operations on the data object for all users; in response to a second user triggering a rollback operation during approval, releasing the approval lock held by the second user, changing the business state from a pending approval state to a rollback modification state, allowing the first user to reacquire the write lock; in response to a first user triggering a withdrawal operation before the second user acquires the approval lock while the data object is in a pending approval state, reverting the business state from a pending approval state to an editable state, and reallocating a write lock to the first user.

[0012] According to embodiments of this disclosure, the method further includes: in response to a data object entering a pending approval state, evaluating the attribute data of the data object according to preset approval rules; and automatically adjusting the corresponding approval path when the attribute data meets preset triggering conditions.

[0013] According to embodiments of this disclosure, the method further includes: detecting the connection status between multiple users and the application software system; if any user's connection is found to be unsatisfactory within a preset first time threshold, releasing all allocated locks held by that user in the application software system; monitoring whether a user holding a write lock or approval lock has any interactive operation within a preset second time threshold; if no interactive operation is detected within the second time threshold, issuing a timeout reminder to the user; if no response is received from the user within a third time threshold after issuing the timeout reminder, automatically releasing the lock held by the user.

[0014] According to embodiments of this disclosure, the method further includes: in response to a change in the business state of a data object, saving a data snapshot containing the attribute data of the data object; wherein multiple saved data snapshots form a version chain to compare the differences between different versions of the data object.

[0015] This disclosure also provides a concurrent access control system, comprising: an acquisition module, configured to acquire the user's declared operation intent and user role in response to a user's request to access a data object in an application software system; an allocation module, configured to allocate a corresponding lock to the user from a variety of preset lock types based on the operation intent, user role, and business status of the data object, wherein the lock types include at least a read lock that allows multiple read operations to coexist, a write lock that allows write operations, and an approval lock that allows approval operations, wherein read locks and write locks can coexist, and write locks and approval locks are mutually exclusive; a determination module, configured to determine the user's operation permissions on the data object based on the lock type; and a conversion module, configured to automatically trigger the release or conversion of the allocated lock when the business status of the data object changes due to the user's operation within the operation permissions.

[0016] In another aspect, this disclosure provides an electronic device, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0017] (III) Beneficial Effects

[0018] The concurrent access control method, system, and electronic device provided in this disclosure have at least the following technical effects:

[0019] (1) Improved concurrency efficiency: It supports one editor and multiple viewers to access the same data object at the same time, and different data objects can be edited by different users at the same time, which significantly improves the efficiency of multi-user collaborative work;

[0020] (2) Smart lock allocation: Based on the operation intention, user role and the current business status of the data object, the minimum privilege lock is automatically allocated. At the same time, online upgrading and downgrading of read locks and write locks are supported. There is no need to close and reopen the data object, reducing unnecessary access blocking.

[0021] (3) Workflow linkage: The acquisition and release of locks are automatically driven by the business state machine. When the state changes, the lock can be automatically released or converted. Furthermore, the conditional approval mechanism can automatically select the corresponding approval path based on the attribute data of the data object, thereby ensuring data security and process compliance.

[0022] (4) Data Dependency Cascading Handling: Construct a dependency graph between data objects. When an upstream data object changes, automatically execute differentiated processing strategies based on the current business status of the downstream data object to prevent business decisions from being made based on expired data.

[0023] (5) Version Snapshot and Traceability: Automatically save data snapshots and form a version chain at the business status transition node, supporting the comparison of differences between different versions, thereby assisting the reviewing user to quickly locate the changed content;

[0024] (6) Lock lifecycle protection: Through connection status detection and idle timeout dual mechanisms, the lock can be automatically released when the user is abnormally offline or has no operation for a long time, so as not to block the subsequent workflow. Attached Figure Description

[0025] To gain a more complete understanding of this disclosure and its advantages, reference will now be made to the following description taken in conjunction with the accompanying drawings, wherein:

[0026] Figure 1 A flowchart illustrating the concurrent access control method provided in an embodiment of this disclosure is shown schematically.

[0027] Figure 2 The diagram illustrates a planning state machine and condition approval path provided in an embodiment of this disclosure.

[0028] Figure 3 This illustration schematically depicts a data dependency-aware cascade processing method provided in an embodiment of this disclosure.

[0029] Figure 4 A flowchart illustrating multi-workstation concurrent access control provided in an embodiment of this disclosure is shown schematically.

[0030] Figure 5 This schematically illustrates a structural block diagram of the concurrent access control system provided in an embodiment of the present disclosure;

[0031] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a concurrent access control method according to an embodiment of the present disclosure. Detailed Implementation

[0032] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0033] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0034] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0035] The accompanying drawings show some block diagrams and / or flowcharts. It should be understood that some blocks or combinations thereof in the block diagrams and / or flowcharts can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing system, so that when executed by the processor, these instructions can create a system for implementing the functions / operations described in these block diagrams and / or flowcharts.

[0036] The Treatment Planning System (TPS) is the core software in the radiotherapy workflow, responsible for functions such as treatment plan design, optimization, dose calculation, and evaluation. In clinical practice, a patient's treatment plan involves collaboration among multiple roles, including physicists, physicians, and quality verification personnel. These roles need to access the same patient's treatment plan data at different times or even simultaneously.

[0037] With the development of radiotherapy technology, the deployment architecture of TPS software is evolving from traditional standalone desktop applications to a networked architecture with multiple workstations sharing a database. In this networked architecture, multiple workstations connect to a shared database server and computing server via a local area network, with all workstations sharing the same patient data. This architecture offers advantages such as centralized data management, shared computing resources, and flexible access from multiple terminals, but it also introduces a core problem that does not exist in standalone TPS systems: concurrent access conflicts among multiple users. In clinical settings, the following concurrent access requests frequently occur: Physician A is editing a patient's treatment plan, and the attending physician wants to view the plan simultaneously to provide adjustment suggestions; Physician A is editing protocol A, and Physician B wants to simultaneously create protocol B for the same patient for comparison; after a plan is submitted for approval, the editor should no longer be able to modify the plan parameters; quality verification personnel need to create verification plans based on approved plans, at which point the plan data must be in a stable locked state; and users forget to close the page after finishing editing and leave, causing the data to be continuously locked, preventing other users from accessing it for extended periods.

[0038] In related technologies, in a single-machine desktop architecture, each workstation runs complete software independently, and data is stored in a distributed manner. The same data is used by only one workstation at a time. While there are no concurrent conflicts, real-time sharing and collaboration of the same data by multiple users is impossible. Some networked architecture systems employ a simple exclusive locking mechanism: when a user accesses patient data, an exclusive lock is placed on all data for that patient, preventing other users from accessing it until the lock is released. For concurrent access requirements, the above solutions have significant shortcomings: the lock granularity is too coarse, using patient or case-by-case exclusive locking, far exceeding the actual data scope that needs protection; there is a lack of read-write separation mechanisms, failing to distinguish between read and write operations, leading to unnecessary access blockages; there is a lack of lock lifecycle management, meaning data remains locked if a user fails to release the lock due to abnormal program exit, network interruption, or forgetting to close it, hindering subsequent workflows; there is a lack of integration with clinical approval processes, as the locking mechanism and the approval status of the plan are independent, failing to automatically adjust access permissions based on the clinical stage of the plan; and there is a lack of data dependency awareness, failing to understand the dependencies between treatment plan data and failing to promptly notify other users accessing downstream data after a user modifies upstream data.

[0039] In view of this, embodiments of the present disclosure provide a concurrent access control method based on operation intent perception, state machine driving, and data dependency linkage.

[0040] like Figure 1 As shown, the flowchart of the concurrent access control method includes S1 to S4.

[0041] In operation S1, in response to a user's request to access a data object in the application software system, the user's declared operation intent and user role are obtained.

[0042] An application software system refers to a software system in which multiple users can access data through a network. For example, such an application software system could be a radiotherapy planning system, which can be used for the design, optimization, dose calculation, and evaluation of radiotherapy plans. It should be noted that the method disclosed herein is not limited to a TPS system, but can also be applied to other application software systems that require concurrent access control for multiple users.

[0043] A data object refers to a target data unit that is accessed and controlled within an application software system. For example, in a TPS system, a data object could be treatment plans for different patients or different treatment plans for the same patient; in other application software systems, a data object could be a document, project, order, or task—a business data unit requiring concurrent access control. Data objects have a business state, which can change based on user actions.

[0044] When users access data objects, they must declare their operational intent. Operational intent refers to the type of operation the user intends to perform on the data object, such as creating, editing, viewing, or approving. User roles refer to the functional division of labor within a business process. For example, in TPS software, user roles could include physicists, doctors, or quality assurance personnel (QA personnel). Taking a typical clinical division of labor as an example, a physicist might be responsible for designing treatment plans, a doctor for approving and managing plan status, and a QA personnel for performing quality assurance. In actual deployment, the correspondence between roles and operations can be configured according to the specific processes of the medical institution, and is not limited to a specific division of labor.

[0045] In operation S2, based on the operation intent, user role, and business status of the data object, a corresponding lock is assigned to the user from a variety of preset lock types. The lock types include at least read locks that allow multiple read operations to coexist, write locks that allow write operations, and approval locks that allow approval operations. Read locks and write locks can coexist, while write locks and approval locks are mutually exclusive.

[0046] The preset lock types include, but are not limited to, read locks, write locks, and approval locks. Read locks allow viewing data content without blocking other users' operations; multiple read locks can coexist. Write locks allow modifying data content; only one write lock can exist on the same data object at a time; write locks and read locks can coexist. Approval locks allow adding approval comments and conclusions but prohibit modification of core data parameters; approval locks and write locks are mutually exclusive. Read locks and write locks are the basic lock types, while approval locks are an optional extended type. The granularity of locks is at the data object level; different data objects under the same parent object are locked independently. A single data object supports one write lock (or approval lock) and multiple read locks coexisting.

[0047] The business status of a data object refers to the stage the data object is in within the current business process. For example, taking a radiotherapy plan as an example, the business status (plan status) may include: draft status (i.e., editable status), indicating the plan is under design and has not yet been submitted for approval; pending approval status, indicating the plan has been submitted and is awaiting approval; approved status (i.e., confirmed status), indicating the plan has been approved and its content should be locked; and returned for modification status, indicating the plan has been returned by the approver and needs to be modified and resubmitted.

[0048] Lock allocation rules can be determined based on three dimensions: "operation intent, user role, and business status." Example allocation rules are shown in the table below:

[0049]

[0050] For operation requests that do not comply with the above rules, the system can directly reject them and provide a reason, such as "This data object is currently being edited by another user. You can choose to view it in read-only mode or send a lock request."

[0051] For example, in a concurrent editing and viewing scenario, user Zhang declares an "edit" intent on data object Plan A (in draft state) on workstation A, and the system assigns a write lock to him; user Wang declares a "view" intent on the same data object on workstation B, and the system assigns a read lock to him. Wang's interface displays "Plan A is being edited by user Zhang," and the edit function button is disabled, but Wang can view all the content of the data object.

[0052] In operation S3, user permissions for data objects are determined based on lock type.

[0053] When a user holds a read lock, their permissions are limited to viewing data content; they cannot perform modification or approval operations. When a user holds a write lock, their permissions include viewing and modifying data content. When a user holds an approval lock, their permissions include viewing data content, adding approval comments and approval conclusions, but they cannot modify core data parameters.

[0054] In operation S4, when the business state of a data object changes due to a user's operation within their operating permissions, the release or conversion of the allocated lock is automatically triggered.

[0055] This embodiment of the disclosure binds the acquisition and release of locks to business state transitions, with lock flow automatically triggered by state changes. For example, taking a radiotherapy plan: when the plan is in draft state, the physicist holds a write lock for editing; after the physicist submits the plan, the plan state changes to pending approval, and the system automatically releases the write lock held by the physicist. When the doctor performs an approval operation on the plan in the pending approval state, they acquire an approval lock; if approval is granted, the plan state changes to approved, the approval lock is automatically released, and the plan becomes read-only; if approval is rejected, the plan state changes to rejected for modification, the approval lock is released, and the physicist can reacquire the write lock for modification.

[0056] Through the state machine-driven automatic lock transition mechanism described above, the lock's lifecycle can be synchronized with the business state, thereby ensuring that at each node of the business state transition, the access permissions of the data object match the current business stage, ultimately guaranteeing data consistency and process security in multi-user concurrent access scenarios.

[0057] Understandably, by employing intent awareness, smart lock allocation, and state machine-driven automatic lock transitions, multiple users can securely and efficiently access shared data objects concurrently. In an exemplary application of a radiotherapy planning system, this method enables multiple users to simultaneously access the same patient's treatment plan data without conflict, effectively improving the parallel efficiency of clinical collaboration while ensuring data consistency and medical safety.

[0058] In embodiments of this disclosure, the method further includes: when a user holds a read lock to access a data object, in response to an upgrade request issued by the user, if it is determined that the read lock meets the preset upgrade conditions, the read lock is upgraded to a write lock; or when a user holds a write lock, in response to a downgrade request issued by the user, the write lock is downgraded to a read lock.

[0059] When a user holds a read lock to access a data object, their interface is in read-only mode. If the user needs editing permission, they can issue an upgrade request, such as by clicking the "Request Edit Permission" button on the interface or executing a specific shortcut key. After receiving the upgrade request, the system can determine whether the current read lock meets the preset upgrade conditions. The preset upgrade conditions may include: the current data object does not have an active write lock or approval lock (i.e., neither the write lock nor the approval lock is held by other users); the current data object's business status allows editing operations (e.g., the plan status is draft or returned for modification); and the current user's role has editing permissions (e.g., the user is a physicist). When all the above conditions are met, the system can directly upgrade the user's read lock to a write lock, and the user interface automatically switches from read-only mode to edit mode without closing the current page and reopening the data object. If the upgrade conditions are not met (e.g., another user already holds a write lock), the system can prompt the user with the current write lock holder's information and suggest that the user try again later or send a collaboration request to the lock holder.

[0060] When a user holds a write lock and performs an editing operation, their interface is in edit mode. If the user has finished editing or does not need to modify permissions temporarily, they can issue a downgrade request, such as by clicking the "Switch to View" button or performing a corresponding interactive operation. In response to the downgrade request, the system can downgrade the user's write lock to a read lock. The downgrade operation releases the write lock resource, allowing other users who need to edit the data object to acquire the write lock. Simultaneously, the current user retains read-only access to the data object and can continue browsing the opened content without closing and reopening the interface. Furthermore, since the write lock holder's voluntary relinquishment of editing permissions does not cause data consistency conflicts, the downgrade operation can be performed without any conditional checks.

[0061] For example, physicist Li opens Plan A in "View Plan" mode. The system assigns a read lock to it, and the interface is in read-only mode. During the viewing process, Li notices that the optimization weights of the target area need adjustment, so he clicks the "Request Edit Permission" button on the interface. The system detects that Plan A currently has no write lock or the approval lock is held by another user, Plan A is in draft status, and Li's role is physicist, meeting the upgrade conditions. At this point, the system directly upgrades the read lock held by Li to a write lock, and the interface automatically switches to edit mode. Li immediately begins adjusting the optimization parameters. After the modification is completed, Li clicks the "Switch to View" button, and the system downgrades the write lock held by him to a read lock. The interface switches back to read-only mode, and Li can continue to browse the modified plan. At the same time, the write lock resource is released, and other users who need to edit the plan can acquire the write lock. Throughout the entire upgrade and downgrade process, Li does not need to close or reopen the Plan A window.

[0062] Understandably, by introducing a dynamic escalation and escalation mechanism between read locks and write locks, the operational flexibility and work efficiency of users in multi-role collaborative workflows are significantly improved, avoiding the operational burden and context loss caused by frequently closing and reopening data objects.

[0063] Based on the above embodiments, in this embodiment, when the business status of a data object changes due to a user's operation within their operating permissions, the release or conversion of the allocated lock is automatically triggered, including: in response to a first user triggering a submit operation on the data object, releasing the write lock held by the first user, changing the business status of the data object from an editable state to a pending approval state, and allocating a read lock to the first user; in response to a second user triggering an approval operation during approval, releasing the approval lock held by the second user, changing the business status of the data object from a pending approval state to a confirmed state, and allowing only read operations on the data object for all users; in response to a second user triggering a rollback operation during approval, releasing the approval lock held by the second user, changing the business status from a pending approval state to a rollback modification state, allowing the first user to reacquire the write lock; in response to a first user triggering a withdrawal operation before the second user acquires the approval lock while the data object is in a pending approval state, reverting the business status from a pending approval state to an editable state, and reallocating a write lock to the first user.

[0064] Figure 2 The diagram illustrates a planning state machine and condition approval path provided in an embodiment of this disclosure.

[0065] like Figure 2As shown, when the first user (e.g., a physicist) completes editing a data object and triggers a submit operation, the system first releases the write lock held by that user, then changes the data object's business status from editable (e.g., draft) to pending approval, and assigns a read lock to that user, granting them only read-only permissions during subsequent review processes. Simultaneously, the system can send an approval request to a second user (e.g., a doctor) with approval permissions via message notifications, informing them of the pending approval plan. When the second user approves the plan in the pending approval state and triggers a rollback operation, the system first releases the approval lock held by the second user, then changes the business status from pending approval to rollback modification, and simultaneously notifies the first user that the plan has been rolled back and the reason for the rollback. After the status change, the first user can reacquire the write lock, modify the plan, and resubmit. Furthermore, when a data object is in the pending approval state and before the second user has acquired the approval lock, the first user can proactively trigger a rollback operation if they find that additional modifications are needed. In response to a withdrawal operation, the system can directly revert the business status from pending approval to editable, and reassign a write lock to the first user, allowing them to continue editing the plan. In the approved scenario, the second user acquires the approval lock, reviews the plan, fills in their approval comments, and executes the approval operation. Then, the system releases the approval lock held by the second user, changing the business status from pending approval to approved. All users then have read-only access to the plan, and the plan enters a locked archive state. For approved plans, if modifications are needed, users (such as the original approving physician or a higher-level physician) can, after identity verification and filling in the reason for revocation, execute a revocation operation, reverting the business status from approved to draft. The physicist can then reacquire a write lock for editing.

[0066] It should be noted that all the above state transition operations require authentication (such as username and password) to ensure traceability and security. Furthermore, the binding relationship between state changes and lock release / assignment is automatically executed by the system, eliminating the need for manual management of lock resources by the user.

[0067] Understandably, by binding the lock lifecycle to the business state transition of data objects, the release, allocation, or transition of locks is automatically triggered by state changes, thereby achieving seamless and automated lock resource management.

[0068] In embodiments of this disclosure, the method further includes: in response to a data object entering a pending approval state, evaluating the attribute data of the data object according to preset approval rules; and automatically adjusting the corresponding approval path when the attribute data meets preset triggering conditions.

[0069] When a data object (such as a treatment plan) enters a pending approval state due to a user-triggered submission, the system can automatically evaluate the attribute data of the data object according to preset approval rules. Attribute data may include dose statistics (such as target coverage, maximum dose to organs at risk, hotspot locations and values), plan technical characteristics (such as whether volumetric modulated arc therapy (VMT) is used, whether stereotactic radiotherapy is used, whether it is multi-particle combined therapy, and whether robust optimization is enabled), patient clinical information (such as whether it is re-radiotherapy and whether there are high-risk underlying diseases), and historical approval records, etc.

[0070] Pre-configured approval rules are set up by users with administrative privileges (such as department heads or system administrators) and can include one or more trigger conditions and their corresponding approval path adjustment strategies. Trigger conditions can be defined using logical expressions, supporting AND and OR combinations of multiple conditions. Adjustments to the approval path can include adding additional approval levels, replacing approver roles, initiating parallel co-signing processes, or skipping certain routine approval steps.

[0071] When the system determines that attribute data meets preset trigger conditions, it can automatically adjust the corresponding approval path. For example, when the maximum brainstem dose in the plan exceeds 45 Gy (close to the 50 Gy tolerance threshold), the trigger condition is met, and the system can automatically add a department head approval step to the original approval path to ensure that high-risk plans receive a higher level of review. Another example is when the plan uses an unconventional segmentation pattern; the system can automatically adjust the approval path from the attending physician's approval to parallel approval by the head of the physics department and the attending physician. Yet another example is for routine plans that have been confirmed as low-risk after condition assessment; the system can trigger a simplified approval path, skipping certain unnecessary approval steps to shorten the approval waiting time.

[0072] Understandably, by introducing a conditional approval mechanism based on attribute data assessment, the approval path can be dynamically and adaptively adjusted according to the risk level, technical complexity, and characteristics of the data object, thereby achieving refined management and differentiated processing of the approval process.

[0073] In embodiments of this disclosure, the method further includes: constructing a dependency chain representing the dependencies between data objects; in response to a change event of an upstream data object, determining the downstream data object affected by the change event based on the dependency chain; and executing a processing strategy corresponding to the current business state of the downstream data object.

[0074] A dependency chain is a directed graph where nodes represent data objects, and directed edges represent the dependencies between data objects. The edges point from upstream to downstream, meaning that an upstream data object is a prerequisite for the computation or generation of a downstream data object. Dependency chains can be pre-defined according to business rules during system initialization, or they can be dynamically updated as association operations between data objects occur.

[0075] Figure 3 The illustration shows a schematic diagram of the data dependency-aware cascade processing provided in an embodiment of the present disclosure.

[0076] For example, such as Figure 3 As shown, the data objects in a radiotherapy plan exist within a dependency chain: image sequence → delineation structure set → planning parameters → dose distribution → evaluation metrics → report document. When an upstream data object undergoes a change event, such as a physicist modifying the target delineation area or adjusting planning parameters, the system can perform an impact analysis based on the dependency chain. This involves traversing the edges of the directed graph to identify all downstream data objects directly or indirectly affected by the change event. The identified downstream data objects can include first-level downstream objects that directly depend on the changed object, as well as second- and third-level downstream objects affected through the dependency chain. For example, modifying the delineation structure set can directly affect planning parameters and dose distribution, and indirectly affect evaluation metrics and report documents through dose distribution.

[0077] For each identified downstream data object, the system can obtain its current business status and execute the corresponding processing strategy based on the business status. The business status of a data object can include editable status (such as draft), pending approval status, approved status, etc., with different statuses corresponding to different processing strategies.

[0078] Understandably, by constructing a dependency chain and executing differentiated cascading handling strategies based on the business status of downstream data objects, the automatic perception and closed-loop management of the impact of upstream changes on downstream is achieved, thereby effectively avoiding decision-making errors caused by upstream data modifications that are not detected in a timely manner downstream.

[0079] Based on the above embodiments, in this embodiment, a processing strategy corresponding to the business status is executed, including: when the downstream data object is in an editable state, marking its associated dependent data as expired and issuing a prompt message to the user; when the downstream data object is in a pending approval state, automatically reverting its business status to the editable state and releasing the allocated lock corresponding to the pending approval state; when the downstream data object is in a confirmed state, keeping its business status unchanged and adding a data expiration warning label to the operation interface of the application software system.

[0080] When upstream data objects change, the system can execute differentiated cascading handling strategies based on the different business states of downstream data objects, in order to balance the relationship between data consistency and the seriousness of business processes.

[0081] For example, continue to refer to Figure 3When a physicist modifies the outline structure set (upstream data change), the system identifies the affected downstream data objects based on the dependency chain, such as plan parameters, dose distributions, evaluation metrics, and report documents. For downstream data objects in an editable state (e.g., draft), the system can mark their associated dependent data as "outdated" or "expired." Simultaneously, it can send a notification to the user currently holding access to the data object (e.g., the physicist editing the plan), informing them that the upstream data has changed and related calculations or checks need to be re-executed. For downstream data objects in a pending approval state, they have already entered the approval process. If they remain in the pending approval queue, approvers may make incorrect decisions based on outdated data. Therefore, the system can automatically revert their business status to an editable state (e.g., from "pending approval" to "draft") and release the approval lock associated with the data object in the pending approval state. After the status revert, the original approval process is interrupted, and the data object re-enters the editable scope. Simultaneously, the system can notify relevant users (such as the physicist who submitted the plan for approval and the physician who intends to approve it) that the approval process has been interrupted due to upstream data changes, requiring the physicist to reprocess and resubmit. For downstream data objects in a confirmed state (such as approved), the system can maintain the business status of the data object unchanged, without automatically reverting its status or releasing any lock resources. However, the system can add a visual data expiration warning label to the application software system's operation interface, such as adding a red warning icon to the affected plans in the plan list. The system can also notify the original approving physician and relevant physicists, reminding them that the upstream data has changed, allowing the physician or physicist to determine whether the approved status needs to be revoked and the plan re-evaluated and approved. In more complex change scenarios, such as upstream changes involving modifications to the data object type (e.g., reclassifying a structure from "organ at risk" to "target area"), the system, in addition to the above processing strategies, can further suspend the editing permissions of the relevant draft plan write lock, requiring the physicist to confirm the impact of the structure type change on the current plan via a pop-up window. Editing permissions are restored after the physicist explicitly selects "continue editing."

[0082] For example, a patient has three treatment plans: Plan A (draft), Plan B (pending approval), and Plan C (approved). When the physicist modifies the target area delineation for this patient, the system automatically executes a cascading process. Specifically, for Plan A, its dosage calculation result is marked as "expired," and a pop-up message is displayed to the physicist currently editing Plan A: "Delineation has been updated, dosage is invalid, please recalculate." For Plan B, its status is automatically reverted from pending approval to draft, the approval lock is released, and both Physician Li and Physician Zhang are notified. For Plan C, its approved status remains unchanged, a red warning label is added to the interface: "Upstream delineation has been updated; this plan's dosage is based on the old delineation," and the original approving physician, Li, is notified.

[0083] Understandably, a tiered processing strategy designed for different business states of downstream data objects can minimize the impact of downstream data changes on the workflow while ensuring data consistency, and at the same time guarantee the seriousness and traceability of confirmed data.

[0084] In embodiments of this disclosure, the method further includes: detecting the connection status between multiple users and the application software system; if any user's connection is found to be unsatisfactory within a preset first time threshold, releasing all allocated locks held by that user in the application software system; monitoring whether a user holding a write lock or approval lock has any interactive operation within a preset second time threshold; if no interactive operation is detected within the second time threshold, issuing a timeout reminder to the user; if no response is received from the user within a third time threshold after issuing the timeout reminder, automatically releasing the lock held by the user.

[0085] In some exemplary embodiments, a heartbeat detection mechanism can be used to monitor the connection status between multiple users and the application software system. Clients can send heartbeat signals to the server at preset intervals (e.g., every 60 seconds) to indicate that their connection is active. If the system detects that any user's connection does not meet preset connection conditions (e.g., no valid heartbeat signal is received) within a preset first time threshold (e.g., for more than 5 consecutive minutes), the system can determine that the user is in an abnormal offline state (e.g., device power failure, network interruption, etc.) and automatically release all allocated locks (including read locks, write locks, and approval locks) held by that user in the application software system. In other scenarios, if the system detects that all users' connections do not meet preset connection conditions within a preset first time threshold (e.g., all network connections between the server and all clients are interrupted), the system can determine that all users are in an abnormal offline state and automatically release all allocated locks (including read locks, write locks, and approval locks) in the application software system, restoring the system to an unlocked state to avoid historical locks remaining after a new user logs in.

[0086] Simultaneously, the system can monitor whether the user holding the write lock or approval lock engages in interactive operations within a preset second time threshold. This second time threshold can be configured according to clinical operation characteristics, for example, set to 30 minutes or 60 minutes. Interactive operations can include any actions indicating the user is still active, such as keyboard input, mouse clicks, or touch operations on the client. If no interactive operation is detected within the second time threshold (i.e., the user has entered an idle state), the system can first issue a timeout reminder to the user, such as a pop-up message saying, "You have not operated for a long time. Do you want to continue editing? Please click OK to retain editing permissions." If the user does not respond within a third time threshold (e.g., 2 minutes or 5 minutes) after the timeout reminder (i.e., no confirmation is received from the user), the system can automatically release the write lock or approval lock held by the user. After the lock is released, the system can notify other users waiting for locks or record an audit log.

[0087] In other embodiments, users can actively release their own write locks or approval locks, or transfer write locks to designated users. Simultaneously, when a user requests to acquire a write lock already held by another user, the system can send a lock request notification to the lock holder, who can choose to release the lock, transfer it to the requester, or reject the request. Furthermore, users with administrative privileges can view the status of all active locks and, after authentication, forcibly release any lock. Forced release operations must be logged in detail for compliance review.

[0088] For example, physicist Zhang is editing plan A, and his write lock is active. At this time, Zhang's workstation loses connection to the server due to an unexpected power outage. The server does not receive a heartbeat signal from Zhang's client for five consecutive minutes, determines that Zhang is abnormally offline, automatically releases all locks held by him, and records an audit log. Zhang can reacquire the write lock and continue editing after logging back in.

[0089] Understandably, the automatic lock reclamation mechanism, which uses heartbeat detection and idle interaction timeout monitoring, effectively solves the problem of long-term lock resource occupation caused by abnormal user offlineness or prolonged idleness.

[0090] In embodiments of this disclosure, the method further includes: in response to a change in the business state of a data object, saving a data snapshot containing the attribute data of the data object; wherein multiple saved data snapshots form a version chain to compare the differences between different versions of the data object.

[0091] When the business status of a data object changes (submitted for approval, approved, or returned), the system can automatically save a data snapshot containing the attribute data of that data object. Attribute data can include a summary of planning parameters (such as target area prescription dose, beam angle, number of scan points, optimization constraints, etc.) and a dose statistics summary (such as target area coverage, maximum dose to organs at risk, conformity index, and other key indicators). Each snapshot saved during a business status transition can be automatically completed by the system, without manual intervention from the user. Furthermore, multiple saved data snapshots can be chained together in chronological order to form a version chain, with each version corresponding to the data status at the time of a status transition.

[0092] Once the version chain is established, the system allows users to compare the differences between different versions of the same data object. For example, approving physicians can compare parameter modifications made by physicists between the first submission (version V1) and the second submission (version V3) to pinpoint which optimization constraints or dosage targets were adjusted in each submission and determine whether the modifications meet clinical requirements. Difference comparisons can highlight newly added, deleted, or numerically changed content and present it visually (e.g., in a table comparison or split-screen display).

[0093] In addition, the system can record audit information for all lock operations and status changes. Audit logs can include operation time, operator, operation type (e.g., acquire lock, release lock, submit for approval, approve, return, etc.), operation object (patient identifier / plan identifier), lock type (read lock, write lock, approval lock), operation result (success / failure), and source IP address. Audit logs support multi-dimensional queries and can be used for clinical quality traceability and compliance review.

[0094] For example, after physicist Zhang completes editing Plan A, he submits it for approval. The system responds by changing the business status from draft to pending approval, automatically saving a data snapshot V1 of Plan A. This snapshot includes key dose statistics such as target coverage (D95%) and brainstem Dmax, as well as optimization constraint parameters. Simultaneously, the system detects that the brainstem Dmax value is 55.2 Gy (RBE), exceeding the hospital's clinical threshold of 54 Gy (RBE), and the approval path automatically escalates to "physicist → doctor → department head." When doctor Li approves the plan, the system displays a warning message indicating that the brainstem Dmax exceeds the limit. Li believes that the target coverage (D95%) does not meet clinical requirements and returns the plan. The system responds by changing the status to "returned for modification," automatically saving a data snapshot V2. Zhang modifies the plan and resubmits it; the system saves snapshot V3. Dr. Li accessed the version comparison function on the approval interface, comparing the snapshot differences between V1 and V3. He confirmed that Zhang had increased the target area D95% from 92.3% to 95.1% and reduced the brainstem Dmax to 53.1 Gy (RBE), confirming the modifications were complete, and approved the plan. The system automatically saved snapshot V4 upon approval, putting the plan in the approved state. If Zhang immediately discovers an error in the parameters after submission, and Dr. Li has not yet started the approval process (i.e., has not acquired the approval lock), Zhang can perform a "withdraw submission" operation. The system responds to the withdrawal operation, reverting the plan's status from pending approval to draft and reallocating a write lock to Zhang. During this process, snapshot V1 remains in the version chain, recording the submission state before withdrawal, but does not affect Zhang's continued editing. After modification, Zhang can resubmit, and the system saves a new snapshot V2 (after V1 in the version chain). The approving doctor can compare the differences between V1 and V2 during subsequent review to understand the adjustments made by the physicist before and after withdrawal.

[0095] Figure 4 A flowchart illustrating concurrent access control for multiple workstations provided in an embodiment of this disclosure is shown schematically.

[0096] like Figure 4As shown, firstly, based on three dimensions of information—operation intent, user role, and plan status—read locks, write locks, or approval locks are automatically assigned to users, achieving intelligent lock allocation. Secondly, when the plan status changes (e.g., submitted for approval, approved, returned for modification), lock release and acquisition are automatically triggered, eliminating the need for manual lock resource management by the user. Then, when upstream data objects change, differentiated cascading actions are automatically executed based on the business status of downstream data objects (draft, pending approval, or approved), including but not limited to marking expired data, automatically returning pending approval plans, or adding expired warning labels. Furthermore, through mechanisms such as heartbeat detection, idle timeout monitoring, proactive release, lock request notification, lock transfer, and administrator-forced release, the entire lifecycle of locks is managed. Finally, when the plan status changes, a data snapshot is automatically saved to form a version chain, supporting comparison of differences between different versions. Simultaneously, audit logs of all lock operations and status changes can be recorded, enabling version snapshots and audit traceability. Through the coordinated execution of the above steps, this embodiment of the disclosure achieves secure, efficient, and traceable collaborative management of data in a multi-user environment.

[0097] Figure 5 A schematic block diagram of the concurrent access control system provided in an embodiment of this disclosure is shown.

[0098] like Figure 5 As shown, the concurrent access control system 500 of this embodiment includes an acquisition module 501, an allocation module 502, a determination module 503, and a conversion module 504.

[0099] According to some embodiments of this disclosure, the concurrent access control system 500 can be used to implement the reference. Figures 1-4 The concurrent access control method described according to embodiments of this disclosure.

[0100] The acquisition module 501 is used to respond to a user's request to access data objects in the application software system and to acquire the user's declared operation intent and user role.

[0101] The allocation module 502 is used to allocate corresponding locks to users from a variety of preset lock types based on the operation intent, user role and business status of data objects. The lock types include at least read locks that allow multiple read operations to coexist, write locks that allow write operations and approval locks that allow approval operations. Read locks and write locks can coexist, while write locks and approval locks are mutually exclusive.

[0102] The determination module 503 is used to determine the user's operation permissions on data objects based on the lock type.

[0103] The conversion module 504 is used to automatically trigger the release or conversion of the assigned lock when the business state of a data object changes due to the user's operation within the operating permissions.

[0104] It is understood that the acquisition module 501, allocation module 502, determination module 503, and conversion module 504 can be implemented in a single module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in a single module. According to embodiments of this disclosure, at least one of the acquisition module 501, allocation module 502, determination module 503, and conversion module 504 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable method of integrating or packaging circuitry, or as hardware or firmware implementation, or as a suitable combination of software, hardware, and firmware implementations. Alternatively, at least one of the acquisition module 501, allocation module 502, determination module 503, and conversion module 504 can be at least partially implemented as a computer program module, which, when run by a computer, can execute the function of the corresponding module.

[0105] It should be understood that the concurrent access control system in the embodiments of this disclosure corresponds to the concurrent access control method in the embodiments of this disclosure, and their specific implementation details are the same, so they will not be repeated here.

[0106] Figure 6 A block diagram of an electronic device suitable for implementing a concurrent access control method according to an embodiment of the present disclosure is shown schematically.

[0107] like Figure 6 As shown, an electronic device 600 according to an embodiment of the present disclosure includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory 602 or a program loaded from a storage portion 608 into a random access memory 603. The processor 601 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different steps of the method flow according to an embodiment of the present disclosure.

[0108] Random access memory 603 stores various programs and data required for the operation of electronic device 600. Processor 601, read-only memory 602, and random access memory 603 are interconnected via bus 604. Processor 601 executes various steps of the method flow according to embodiments of the present disclosure by executing programs in read-only memory 602 and / or random access memory 603. It should be noted that programs may also be stored in one or more memories other than read-only memory 602 and random access memory 603. Processor 601 may also execute various steps of the method flow according to embodiments of the present disclosure by executing programs stored in one or more memories.

[0109] According to embodiments of this disclosure, the electronic device 600 may further include an input / output interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card, such as a local area network card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0110] Embodiments of this disclosure also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0111] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this disclosure, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include the read-only memory 602 described above, and / or random access memory 603, and / or one or more memories other than read-only memory 602 and random access memory 603.

[0112] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this disclosure.

[0113] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0114] In embodiments of this disclosure, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by processor 601, it performs the functions defined in the system of embodiments of this disclosure. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0115] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can execute entirely on a user computing device, partially on a user device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0116] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0117] Those skilled in the art will understand that the features described in the various embodiments of this disclosure can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments of this disclosure can be combined and / or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

Claims

1. A concurrent access control method, characterized in that, include: In response to a user's request to access data objects in the application software system, the user's declared operational intent and user role are obtained; Based on the operation intent, user role, and business status of the data object, a corresponding lock is assigned to the user from a variety of preset lock types. The lock types include at least a read lock that allows multiple read operations to coexist, a write lock that allows write operations, and an approval lock that allows approval operations. The read lock and the write lock can coexist, and the write lock and the approval lock are mutually exclusive. Based on the lock type, determine the user's operation permissions for the data object; When the business status of the data object changes due to the user's operation within the operation permissions, the release or conversion of the assigned lock is automatically triggered.

2. The method according to claim 1, characterized in that, The method further includes: Construct a dependency chain representing the dependencies between the data objects; In response to a change event of an upstream data object, determine the downstream data object affected by the change event based on the dependency chain; Based on the current business status of the downstream data object, execute the processing strategy corresponding to the business status.

3. The method according to claim 2, characterized in that, The execution of the processing strategy corresponding to the business state includes: When the downstream data object is in an editable state, its associated dependent data is marked as expired, and a prompt message is sent to the user. When the downstream data object is in the pending approval state, its business status is automatically rolled back to the editable state, and the allocated lock corresponding to the pending approval state is released. When the downstream data object is in a confirmed state, its business status remains unchanged, and a data expiration warning label is added to the operation interface of the application software system.

4. The method according to claim 1, characterized in that, The method further includes: When the user holds the read lock to access the data object, in response to the user's upgrade request, if it is determined that the read lock meets the preset upgrade conditions, the read lock is upgraded to the write lock; or When the user holds the write lock, in response to the user's downgrade request, the write lock is downgraded to the read lock.

5. The method according to claim 1, characterized in that, When the business status of the data object changes due to the user's operation within the operating permissions, the automatic release or conversion of the allocated lock is triggered, including: In response to the first user triggering a data object submission operation, the write lock held by the first user is released, the business status of the data object is changed from editable to pending approval, and a read lock is assigned to the first user. In response to the second user triggering an approval operation during the approval process, the approval lock held by the second user is released, and the business status of the data object is changed from the pending approval status to the confirmed status. The data object is only allowed to perform read operations for all users. In response to the second user triggering a rollback operation during approval, the approval lock held by the second user is released, and the business status is changed from the pending approval status to the rollback modification status, so as to allow the first user to reacquire the write lock; In response to the first user triggering a withdrawal operation before the data object is in the pending approval state and the second user has acquired the approval lock, the business state is rolled back from the pending approval state to the editable state, and a write lock is reassigned to the first user.

6. The method according to claim 1 or 5, characterized in that, The method further includes: In response to the data object entering a pending approval state, the attribute data of the data object is evaluated according to preset approval rules; When the attribute data meets the preset triggering conditions, the corresponding approval path is automatically adjusted.

7. The method according to claim 1, characterized in that, The method further includes: Detect the connection status between multiple users and the application software system; If any user's connection is found to be unsatisfactory within a preset first time threshold, release all allocated locks held by that user in the application software system. Monitor whether the user holding the write lock or approval lock has any interactive operation within a preset second time threshold; If no interactive operation is detected within the second time threshold, a timeout reminder is sent to the user; If no response is received from the user within the third time threshold after the timeout reminder is issued, the lock held by the user will be automatically released.

8. The method according to claim 1, characterized in that, The method further includes: In response to a change in the business status of the data object, a data snapshot containing the attribute data of the data object is saved; The multiple data snapshots form a version chain to compare the differences between different versions of the data object.

9. A concurrent access control system, characterized in that, include: The acquisition module is used to acquire the user's declared operation intent and user role in response to the user's request to access data objects in the application software system. The allocation module is used to allocate a corresponding lock to the user from a variety of preset lock types based on the operation intention, user role and business status of the data object. The lock types include at least a read lock that allows multiple read operations to coexist, a write lock that allows write operations and an approval lock that allows approval operations. The read lock and the write lock can coexist, and the write lock and the approval lock are mutually exclusive. The determination module is used to determine the user's operation permissions on the data object based on the lock type; The conversion module is used to automatically trigger the release or conversion of the allocated lock when the business status of the data object changes due to the user's operation within the operation permission.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

Images