TW201828100A - File reading and writing method, apparatus and system avoiding conflicts between contents submitted by multiple users when operating the same file - Google Patents

Abstract

This application provides a file reading and writing method, apparatus and system. The file reading and writing method comprises the following steps: receiving an access request, and obtaining file identification information and first user identification information according to the access request; querying a lock file corresponding to the file identification information in a cache server, if the lock file corresponding to the file identification information is not found, obtaining a first source file corresponding to the file identification information from a file server; generating the lock file according to the first user identification information and the first source file, and submitting the lock file to the cache server; and receiving an edit operation on the first source file, and submitting the edited first source file to the cache server. The file reading and writing method of the embodiment of the present application enables a user to have an exclusive operation right of the file during the operation of the file, thereby avoiding conflicts between contents submitted by multiple users when operating the same file, so that the WebIDE system can play a greater role in multiple collaborative development processes.

Description

 File reading and writing method, device and system  

This application relates to the development field of WebIDE (WebIDE is a kind of webpage for users to edit code on a page), and particularly relates to a file reading and writing method, device and system.

GIT (Distributed Version Control System) and SVN (Subversion, Open Source Code Version Control System) are commonly used file version control tools in the development process, which are often used in team development tasks, but these two tools are for systems, environments, and Command proficiency requirements are relatively high, resulting in developers developing low efficiency when using.

At present, some WebIDE development environments (such as Coding.net in China) have enabled developers to write and submit code files in the browser to solve the problem of low efficiency caused by high operating costs. For example, some multi-person collaborative development systems use a client-side cache method, in which multiple developers record the operation of the same file in their own client-side cache, and then submit their own cache operations to The server, the server obtains the cache operations of each client and merges them into a complete operation, and then updates the file. However, the solution has the following problems: (1) The developer's read and write permission to the file is not properly controlled, because the same file can be opened in multiple browsers, or multiple developers open the same file. Write, so at the same time for the same file, there may be cases where different developers open and write different content, resulting in conflicts in the contents of the file when submitting files after writing by different developers. Or the content of the files overlaps each other, which seriously limits the development of multiple developers in multi-person collaborative development; (2) the client needs to have a cache, and needs sufficient permission to operate the cache system, for example The ios system strictly controls the user's permission, or the user manually closes the permission, and the developer will not be able to operate; (3) the contents of the file modification are saved on the user side, if the developer has modified the information but has not yet If you have time to submit to the server, the user will lose data when switching users; (4) all the operation data are Stored in the client-side cache, developers can modify the cache data at will if they have permission, and the security is poor.

The present application is intended to solve at least one of the technical problems in the related art to some extent.

To this end, the first object of the present application is to propose a file reading and writing method, the file reading and writing method.

A second object of the present application is to provide a file reading and writing device.

The third object of the present application is to propose a file reading and writing system.

To achieve the above objective, the first aspect of the present application provides a file reading and writing method, including the steps of: receiving an access request, and obtaining file identification information and first user identification information according to the access request; The server searches for the lock file corresponding to the file identifier information, and if the lock file corresponding to the file identifier information is not queried, the first original file corresponding to the file identifier information is obtained from the file server; a user identification information and the first original file generating a lock file, and submitting the lock file to the cache server; and receiving an edit operation for the first original file, and the edited An original file is submitted to the cache server, so that the cache server updates the lock file according to the edited first original file.

The file reading and writing method of the embodiment of the present application implements a file locking mechanism suitable for the WebIDE system through the cache server, and uses the cache server as a buffer between the file server and the WebIDE server, and uses the cache mechanism to implement the file. Locking, so that the user has the exclusive operation right of the file during the operation of the file, avoiding conflicts between the content submitted by multiple users when operating the same file, so that the WebIDE system can be in multiple collaborative development processes. Play a bigger role. In addition, using the cache mechanism to lock the file is cheaper than modifying the file server's database each time, and the cache mechanism can handle multiple files more flexibly, generate different copies of the same file, and so on. Give users a better experience.

In order to achieve the above objective, the second aspect of the present application provides a file reading and writing device, comprising: a first receiving module, configured to receive an access request; and a first obtaining module, the user acquiring the file according to the access request The identification module and the first user identification information; the query module is configured to query the cache file for the lock file corresponding to the file identifier information; and the second acquisition module is configured to: when the query module is not queried The first original file corresponding to the file identification information is obtained from the file server, and the generating module is configured to use the first user identification information and the first original file. Generating a lock file; submitting a module for submitting the lock file to the cache server; and a second receiving module for receiving an edit operation for the first original file, wherein the submitting The module submits the edited first original file to the cache server, so that the cache server enters the locked file according to the edited first original file. Line updates.

The file reading and writing device of the embodiment of the present application implements a file locking mechanism suitable for the WebIDE system through the cache server, and uses the cache server as a buffer between the file server and the WebIDE server, and uses the cache mechanism to implement the file. Locking, so that the user has the exclusive operation right of the file during the operation of the file, avoiding conflicts between the content submitted by multiple users when operating the same file, so that the WebIDE system can be in multiple collaborative development processes. Play a bigger role. In addition, using the cache mechanism to lock the file is cheaper than modifying the file server's database each time, and the cache mechanism can handle multiple files more flexibly, generate different copies of the same file, and so on. Give users a better experience.

In order to achieve the above object, the collaborative manufacturer embodiment of the present application proposes a file reading and writing system, including: a WebIDE server, a cache server, and a file server, wherein the WebIDE server is configured to receive an access request, and Acquiring the file identification information and the first user identification information according to the access request, and querying the lock file corresponding to the file identification information in the cache server, if the lock file corresponding to the file identification information is not queried, Obtaining, by the file server, the first original file corresponding to the file identification information, and generating a lock file according to the first user identification information and the first original file, and submitting the locked file to the cache a server, and receiving an editing operation for the first original file, and submitting the edited first original file to the cache server; and the cache server is configured to store the lock file, and Updating the locked file according to the edited first original file.

The file reading and writing system of the embodiment of the present application implements a file locking mechanism suitable for the WebIDE system through a cache server, and uses a cache server as a buffer between the file server and the WebIDE server, and uses a cache mechanism to implement the file. Locking, so that the user has the exclusive operation right of the file during the operation of the file, avoiding conflicts between the content submitted by multiple users when operating the same file, so that the WebIDE system can be in multiple collaborative development processes. Play a bigger role. In addition, using the cache mechanism to lock the file is cheaper than modifying the file server's database each time, and the cache mechanism can handle multiple files more flexibly, generate different copies of the same file, and so on. Give users a better experience.

The additional aspects and advantages of the present invention will be set forth in part in the description which follows.

1‧‧‧WebIDE Server

2‧‧‧Cache Server

3‧‧‧File Server

101‧‧‧First Receiver Module

102‧‧‧First acquisition module

103‧‧‧Query Module

104‧‧‧Second acquisition module

105‧‧‧Generation module

106‧‧‧Submit module

107‧‧‧second receiving module

108‧‧‧First Judgment Module

109‧‧‧First reminder module

110‧‧‧Second judgment module

111‧‧‧Update Module

112‧‧‧ third receiving module

113‧‧‧Unlocking module

114‧‧‧fourth receiving module

115‧‧‧Replacement module

116‧‧‧Second prompt module

The above and/or additional aspects and advantages of the present application will become apparent and readily understood from the following description of the embodiments in conjunction with the accompanying drawings in which: Figure 1 is a flow of the file reading and writing method of one embodiment of the present application. 2 is a flow chart of a file reading and writing method according to a specific embodiment of the present application; FIG. 3 is a flowchart of a file reading and writing method according to another embodiment of the present application; FIG. 4 is another specific embodiment of the present application; FIG. 5 is a flow chart of a file reading and writing method according to another embodiment of the present application; FIG. 6 is a schematic structural diagram of a file reading and writing device according to an embodiment of the present application; 7 is a schematic structural diagram of a file reading and writing device according to a specific embodiment of the present application; and FIG. 8 is a schematic structural diagram of a file reading and writing device according to an embodiment of the present application.

The embodiments of the present application are described in detail below, and the examples of the embodiments are illustrated in the drawings, wherein the same or similar reference numerals are used to refer to the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are intended to be illustrative, and are not to be construed as limiting.

Moreover, the terms "first" and "second" are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, features defining "first" and "second" may include one or more of the features either explicitly or implicitly. In the description of the present application, the meaning of "a plurality" is two or more unless specifically and specifically defined otherwise.

Any process or method description in the flowcharts or otherwise described herein can be understood as a module, segment or code representing code that includes one or more executable instructions for implementing the steps of a particular logical function or process. The scope of the preferred embodiments of the present application includes additional implementations in which the functions may be performed in a substantially simultaneous manner or in an opposite order depending on the functions involved. This should be understood by those skilled in the art to which the embodiments of the present application pertain.

1 is a flow chart of a file reading and writing method according to an embodiment of the present application.

As shown in Figure 1, the file reading and writing methods include:

S101. Receive an access request, and obtain file identification information and first user identification information according to the access request.

In the embodiment of the present application, a WebIDE server, a cache server, and a file server are included. The WebIDE server can provide a user interface for editing the file, perform operations in the cache server, or interact with the cache server and the file server. The file server is used to store the code file of the file. For example, the GIT server is used to store the code file of the GIT file, and the SVN server is used to store the code file of the SVN file. The cache server uses a cache mechanism to implement storage-locked files. For example, it can be a noSql cache server, or a Redis, Tair, or other cache server.

It should be understood that the WebIDE server, the cache server, and the file server may be a single server or a server cluster composed of multiple servers.

Specifically, the WebIDE server receives the access request sent by the user A to access a certain file, and obtains the file identification information of the file and the user identification information of the user A. The file identification information is used to query the unique identifier of the file on the server side. For example, the file identification information may be the file path, the file MD5 (Message Digest Algorithm 5, the fifth version of the message digest algorithm). The user identification information is a unique identifier for verifying the identity of the user. For example, the user identification information may be a user ID (identity identification number) or the like.

S102: Query the lock file corresponding to the file identifier information in the cache server, and if the lock file corresponding to the file identifier information is not queried, obtain the first original file corresponding to the file identifier information from the file server.

Specifically, the WebIDE server searches the cache server for the file corresponding to the file identification information according to the file identification information, wherein the file is locked in the cache server, that is, the file is locked. That is to say, when user A requests access to the file, the file is not directly obtained from the file server, but the cache server is first queried whether there is a file that has been locked, if the cache server does not exist. The file that is locked is then retrieved from the file server.

If the WebIDE server does not query the corresponding lock file in the cache server, the original file stored on the file server is currently in an unlocked state, and user A has the permission to obtain the original file from the file server. The original file is locked. Therefore, the WebIDE server finds the corresponding original file according to the file identification information in the file server, and acquires the original file.

S103. Generate a lock file according to the first user identification information and the first original file, and submit the lock file to the cache server.

Specifically, the WebIDE server presents the file content of the original file to the user A, and simultaneously locks the original file according to the user identification information of the user A to generate a locked file containing the original file and the user identification information. Then, the WebIDE server uses the file identification information as the identifier of the locked file, and submits the locked file to the cache server for storage.

It should be understood that after the lock file is stored in the cache server, if the WebIDE server receives the request sent by user B to access the file, the WebIDE server will first query the cache server in the same manner. Is there a lock file corresponding to the file? If the WebIDE server queries the corresponding lock file, because the lock file exists in the cache server, User B is not allowed to obtain the file or is in the state that the file is locked. The file is edited. Thereby, it is possible to avoid the problem that the user A and the user B simultaneously edit the file, causing the edited contents to collide with each other.

S104. Receive an editing operation for the first original file, and submit the edited first original file to the cache server, so that the cache server updates the locked file according to the edited first original file.

Specifically, the user A can edit the file content of the original file. When the user A selects to save the edited content, the WebIDE server submits the edited original file plus the user identification information to the cache server. In other words, the WebIDE server saves the edited content of User A to the cache file of the cache server.

It should be understood that the way the WebIDE server reads and writes files from the file server and presents the contents of the files to the user can be implemented by using existing technologies. For example, the Web IDE server uses the GitLab API or the Svn API to read and write files. The open source JS framework such as ACE realizes the display of archive content. The cache used in the cache server can use SSD (Solid State Drives) to make a cached persistent space for larger storage space, or use a cache solution such as Tair cluster. Since the above schemes are mature technologies, they are not repeated here.

The file reading and writing method of the embodiment of the present application implements a file locking mechanism suitable for the WebIDE system through the cache server, and uses the cache server as a buffer between the file server and the WebIDE server, and uses the cache mechanism to implement the file. Locking, so that the user has the exclusive operation right of the file during the operation of the file, avoiding conflicts between the content submitted by multiple users when operating the same file, so that the WebIDE system can be in multiple collaborative development processes. Play a bigger role. In addition, using the cache mechanism to lock the file is cheaper than modifying the file server's database each time, and the cache mechanism can handle multiple files more flexibly, generate different copies of the same file, and so on. Give users a better experience.

2 is a flow chart of a file reading and writing method according to a specific embodiment of the present application.

As shown in Figure 2, the file reading and writing methods include:

S201. Receive an access request, and obtain file identification information and first user identification information according to the access request.

S202. Query the lock file corresponding to the file identifier information in the cache server. If the lock file corresponding to the file identifier information is not queried, obtain the first original file corresponding to the file identifier information from the file server.

S203. If the locked file corresponding to the file identification information is queried, determine whether the first user identification information matches the second user identification information corresponding to the locked file, and if the first user identification information matches the second user identification information. , then get the lock file from the cache server.

Specifically, if the WebIDE server queries the corresponding lock file in the cache server, it indicates that the original file stored on the file server is currently locked, and the WebIDE server obtains the user identification information of the locked file, and Determining whether the user identification information of the user A matches the user identification information of the locked file, and if the user identification information of the user A matches the user identification information of the locked file, the WebIDE server determines that the user A has the permission. Get the lock file and edit it.

It should be understood that after the user A reads the lock file, the lock file still remains locked in the cache server.

In an embodiment of the present application, if the first user identification information does not match the second user identification information, generating prompt information for refusing to acquire the locked file is generated. Specifically, if the user B accesses the locked file in the cache server, the user identification information of the user B and the user identification information of the locked file do not match, that is, the locked file is locked by the user A, The WebIDE server determines that User B does not have permission to acquire the lock file for editing, and generates a prompt message prompting User B.

In one embodiment of the present application, if the WebIDE server determines that User B does not have permission to acquire the locked file for editing, the WebIDE server may provide User B with a copy of the locked file, and User B may perform the copy. Editing, so that after User A unlocks the locked file, the WebIDE server submits according to the conflict edited by User B after processing the conflict between the copy and the locked file edited by User A. Thus, User B can provide User B with a more friendly operation when there is no permission to edit the locked file.

S204. Receive an editing operation for the locked file, and submit the edited locked file to the cache server, so that the cache server updates the locked file according to the edited locked file.

Specifically, the WebIDE server displays the file content of the locked file to the user A, and the user A can edit the file content. When the user A selects to save the edited content, the WebIDE server adds the edited locked file. The user identification information is submitted to the cache server. In other words, the WebIDE server saves the edited content of User A to the cache file of the cache server.

It should be understood that due to the persistence feature of the cache file in the cache server, the lock file stored by the user A in the cache server is persistently maintained, when the user A switches from one client to another. At the end, the user can display the information and the file identification information of the user A to read the locked file in the cache server for editing.

3 is a flow chart of a file reading and writing method according to another embodiment of the present application.

As shown in Figure 3, the file reading and writing methods include:

S301. Receive an access request, and obtain file identification information and first user identification information according to the access request.

S302. Query the lock file corresponding to the file identifier information in the cache server. If the lock file corresponding to the file identifier information is not queried, obtain the first original file corresponding to the file identifier information from the file server.

S303. Generate a lock file according to the first user identification information and the first original file, and submit the lock file to the cache server.

S304. Receive an editing operation for the first original file, and submit the edited first original file to the cache server, so that the cache server updates the locked file according to the edited first original file.

S305: Obtain a second original file from the file server, and determine whether the first submission information of the locked file in the cache server matches the second submission information of the second original file, if the first submission information matches the second submission information. , the lock file is submitted to the file server, so that the file server replaces the second original file with the lock file.

Specifically, after updating the locked file in the cache server according to the content edited by the user A, the WebIDE server obtains the original file saved in the file server again from the file server, and obtains the submission information of the original file. If the submission information of the locked file in the cache server matches the submission information of the original file in the file server, the WebIDE server asynchronously submits the updated locked file to the file server, and replaces the original file in the file server. For the updated lock file.

S306. If the first submission information does not match the second submission information, update the locked file according to the second original file, update the first submission information according to the second submission information, and submit the updated locked file to the file server. Device.

Specifically, if the submission information of the locked file in the cache server does not match the submission information of the original file in the file server, the original file in the file server has been updated, for example, the user side of the file server through the file server When the original file is updated, the WebIDE server saves the contents of the locked file as a copy, and obtains the contents of the original file, and updates the contents of the locked file according to the content of the original file. After User A resolves the conflict between the content of the locked file and the content of the original file, the WebIDE server updates the submission information of the locked file in the cache server to the submission information of the original file in the file server. Then, the WebIDE server asynchronously submits the updated lock file to the file server, and replaces the original file in the file server with the updated lock file.

4 is a flow chart of a file reading and writing method according to another embodiment of the present application.

As shown in Figure 4, the file reading and writing methods include:

S401. Receive an access request, and obtain file identification information and first user identification information according to the access request.

S402. Query the lock file corresponding to the file identifier information in the cache server. If the lock file corresponding to the file identifier information is not queried, obtain the first original file corresponding to the file identifier information from the file server.

S403, if the locked file corresponding to the file identification information is queried, determining whether the first user identification information matches the second user identification information corresponding to the locked file, and if the first user identification information matches the second user identification information , then get the lock file from the cache server.

S404. Receive an editing operation for the locked file, and submit the edited locked file to the cache server, so that the cache server updates the locked file according to the edited locked file.

S405. Receive an unlock request for the locked file in the cache server, and delete the lock file from the cache server when determining that the first user identifier information matches the second user identifier information corresponding to the lock file.

Specifically, after the user A edits the lock file, the user A can send a request to unlock the lock file, and after receiving the unlock request sent by the user A, the WebIDE server prompts the user to unlock the lock file. And prompt the user to submit the locked file to the file server before unlocking. After the user A confirms that the locked file is unlocked, the corresponding locked file is found in the cache server according to the file identification information, and it is determined whether the user identification information corresponding to the locked file matches the user identification information of the user A. If the user identification information corresponding to the locked file matches the user identification information of user A, the WebIDE server deletes the locked file from the cache server.

It should be understood that after the lock file is deleted from the cache server, if the user B requests access to the file, the WebIDE server further provides the user B with the exclusive operation right of the separate operation file according to the methods of steps S401-S404. .

FIG. 5 is a flow chart of a file reading and writing method according to another embodiment of the present application.

As shown in Figure 5, the file reading and writing method includes:

S501. Receive an access request, and obtain file identification information and first user identification information according to the access request.

S502. Query the lock file corresponding to the file identifier information in the cache server. If the lock file corresponding to the file identifier information is not queried, obtain the first original file corresponding to the file identifier information from the file server.

S503, if the lock file corresponding to the file identifier information is queried, determining whether the first user identifier information matches the second user identifier information corresponding to the lock file, and if the first user identifier information matches the second user identifier information , then get the lock file from the cache server.

S504. If the first user identifier information does not match the second user identifier information, generate prompt information for rejecting the lock file.

S505. Receive a replacement request for the second user identifier information, and replace the second user identifier information with the first user identifier information according to the replacement request, and generate prompt information that the second user identifier information is replaced.

Specifically, if user B does not have permission to acquire the locked file for editing, and user B urgently needs to edit the locked file, and the file is locked by user A, user B can choose to steal the lock and directly have User A who locks the read/write permission of the file becomes user B with permission. That is to say, the user B sends a replacement request for the user identification information corresponding to the locked file in the cache server, and the WebIDE server will lock the user identification information of the file after receiving the replacement request sent by the user B. It is replaced with the user identification information of the user B, and generates prompt information for the user identification information of the locked file to be replaced to prompt the user A.

S506. Receive an editing operation for the locked file, and submit the edited locked file to the cache server, so that the cache server updates the locked file according to the edited locked file.

Specifically, the WebIDE server displays the file content of the locked file to the user B, and the user B can edit the file content. When the user B selects to save the edited content, the WebIDE server adds the edited locked file. User B's user identification information is submitted to the cache server. In other words, the WebIDE server saves the edited content of User B to the lock file of the cache server.

The file reading and writing method of the embodiment of the present application provides functions such as file locking, file unlocking, and lock-up for the user, and solves the problem that the content submitted by the multi-person collaborative development conflicts and covers each other, and uses the cache server at the same time. Saving the lock file can solve the problem of unsynchronized information in multiple WebIDE servers, so that multi-person collaborative development can fully utilize the advantages of fast and environmentally unrestricted.

In order to implement the above embodiments, the present application also proposes a file reading and writing device.

6 is a schematic structural diagram of a file reading and writing device according to an embodiment of the present application. As shown in FIG. 6, the file reading and writing device includes: a first receiving module 101, a first obtaining module 102, an inquiry module 103, and a first The acquisition module 104, the generation module 105, the submission module 106, and the second receiving module 107.

Specifically, the first receiving module 101 is configured to receive an access request. The first obtaining module 102 user obtains the file identification information and the first user identification information according to the access request. Specifically, the first receiving module 101 receives the access request sent by the user A to access a certain file, and the first obtaining module 102 obtains the file identification information of the file and the user identification information of the user A. The file identification information is used to query the unique identifier of the file on the server side. For example, the file identification information may be an archive path, an MD5 of the file, or the like. The user identification information is a unique identifier for verifying the identity of the user. For example, the user identification information may be a user ID or the like.

The query module 103 is configured to query the cache file for the lock file corresponding to the file identifier information. The second obtaining module 104 is configured to obtain the first original file corresponding to the file identification information from the file server when the query module 103 does not query the locked file corresponding to the file identification information. Specifically, the query module 103 queries the cache server for the file corresponding to the file identification information according to the file identification information, wherein the file is locked in the cache server, that is, the file is locked. That is to say, when user A requests access to the file, the file is not directly obtained from the file server, but the cache server is first queried whether there is a file that has been locked, if the cache server does not exist. The file that is locked is then retrieved from the file server. If the query module 103 does not query the corresponding lock file in the cache server, it indicates that the original file stored on the file server is currently in an unlocked state, and user A has the permission to obtain the original file from the file server. And the original file is locked. Therefore, the second obtaining module 104 finds the corresponding original file according to the file identification information in the file server, and acquires the original file.

The generating module 105 is configured to generate a lock file according to the first user identification information and the first original file. The submission module 106 is configured to submit the lock file to the cache server. Specifically, the generating module 105 displays the file content of the original file to the user A, and the generating module 105 locks the original file according to the user identification information of the user A to generate the original file and the user identification information. Lock the file. Then, the submitting module 106 uses the file identification information as the identifier of the locked file, and submits the locked file to the cache server for storage.

The second receiving module 107 is configured to receive an editing operation for the first original file, where the submitting module 106 submits the edited first original file to the cache server, so that the cache server is based on the edited An original file updates the lock file. Specifically, the user A can edit the file content of the original file. When the user A selects to save the edited content, the second receiving module 107 receives the editing operation of the user, and the submitting module 106 will edit the original content. The file plus the user identification information is submitted to the cache server. In other words, the content edited by user A is saved to the lock file of the cache server.

The file reading and writing device of the embodiment of the present application implements a file locking mechanism suitable for the WebIDE system through the cache server, and uses the cache server as a buffer between the file server and the WebIDE server, and uses the cache mechanism to implement the file. Locking, so that the user has the exclusive operation right of the file during the operation of the file, avoiding conflicts between the content submitted by multiple users when operating the same file, so that the WebIDE system can be in multiple collaborative development processes. Play a bigger role. In addition, using the cache mechanism to lock the file is cheaper than modifying the file server's database each time, and the cache mechanism can handle multiple files more flexibly, generate different copies of the same file, and so on. Give users a better experience.

FIG. 7 is a schematic structural diagram of a file reading and writing device according to an embodiment of the present application. As shown in FIG. 7, the file reading and writing device includes: a first receiving module 101, a first obtaining module 102, and an query module 103. The second obtaining module 104, the generating module 105, the submitting module 106, the second receiving module 107, the first determining module 108, the first prompting module 109, the second determining module 110, the updating module 111, The third receiving module 112, the unlocking module 113, the fourth receiving module 114, the replacement module 115, and the second prompting module 116.

Specifically, the first determining module 108 is configured to determine, when the query module 103 queries the locked file corresponding to the file identification information, whether the first user identification information matches the second user identification information corresponding to the locked file. The second obtaining module 104 is further configured to: when the first determining module 108 determines that the first user identification information matches the second user identification information, obtain the locked file from the cache server. Specifically, if the query module 103 queries the corresponding lock file in the cache server, it indicates that the original file stored on the file server is currently locked, and the user identification information of the locked file is obtained. The module 108 determines whether the user identification information of the user A and the user identification information of the locked file match. If the first determining module 108 determines that the user identification information of the user A matches the user identification information of the locked file, User A has permission to acquire the lock file and edit it. Therefore, the second acquisition module 104 obtains the lock file from the cache server.

The first prompt module 109 is configured to generate prompt information for refusing to acquire the locked file when the first determining module 108 determines that the first user identification information does not match the second user identification information. Specifically, if the user B accesses the locked file in the cache server, the first determining module 108 determines that the user identification information of the user B and the user identification information of the locked file do not match, that is, the locked file is If the user A is locked, the first determining module 108 determines that the user B does not have permission to acquire the locked file for editing, and the first prompting module 109 generates a prompting information to prompt the user B.

In one embodiment of the present application, the file reading and writing device further includes a second determining module 110 and an updating module 111. The second obtaining module 104 is further configured to acquire the second original file from the file server. The second determining module 110 is configured to determine whether the first submission information of the locked file in the cache server matches the second submission information of the second original file. The submitting module 106 is further configured to: when the second determining module 110 determines that the first submitted information matches the second submitted information, submit the locked file to the file server, so that the file server replaces the second original file with the locked file. . Specifically, after the submitting module 106 updates the locked file in the cache server according to the content edited by the user A, the second obtaining module 104 acquires the original file saved in the file server from the file server again, and obtains the file from the file server. The submission information of the original file, if the second determining module 110 determines that the submission information of the locked file in the cache server matches the submission information of the original file in the file server, the submitting module 106 asynchronously updates the updated locked file. Submit to the file server and replace the original file in the file server with the updated lock file.

The update module 111 is configured to: when the second determining module 110 determines that the first submission information does not match the second submission information, update the locked file according to the second original file, and update the first submission information according to the second submission information, The submitting module 106 is further configured to submit the updated locked file to the file server. Specifically, if the second determining module 110 determines that the submission information of the locked file in the cache server does not match the submission information of the original file in the file server, the original file in the file server has been updated, for example, the user When the client of the file server updates the original file, the update module 111 saves the content of the locked file as a copy, obtains the content of the original file, and updates the content of the locked file according to the content of the original file. After the user A resolves the conflict between the content of the locked file and the content of the original file, the submitting module 106 updates the submission information of the locked file in the cache server to the submission information of the original file in the file server. Then, the submitting module 106 asynchronously submits the updated locked file to the file server, and replaces the original file in the file server with the updated locked file.

In an embodiment of the present application, the file reading and writing device further includes a third receiving module 112 and an unlocking module 113. The third receiving module 112 is configured to receive an unlock request for a locked file in the cache server. The unlocking module 113 is configured to delete the locked file from the cache server when the first determining module 108 determines that the first user identification information matches the second user identification information corresponding to the locked file. Specifically, after the user A finishes editing the lock file, the user A may send a request to unlock the lock file, and the third receiving module 112 prompts the user after receiving the unlock request sent by the user A. The user will unlock the locked file and prompt the user to submit the locked file to the file server before unlocking. After the user A confirms that the locked file is unlocked, the first determining module 108 finds the corresponding locked file in the cache server according to the file identification information, and determines whether the user identification information corresponding to the locked file is related to the user A. User ID information matches. If the first determining module 108 determines that the user identification information corresponding to the locked file matches the user identification information of the user A, the unlocking module 113 deletes the locked file from the cache server.

In an embodiment of the present application, the file reading and writing device further includes a fourth receiving module 114, a replacement module 115, and a second prompting module 116. The fourth receiving module 114 is configured to receive a replacement request for the second user identification information. The replacement module 115 is configured to replace the second user identification information with the first user identification information according to the replacement request. The second prompt module 116 is configured to generate prompt information that the second user identification information is replaced. Specifically, if user B does not have permission to acquire the locked file for editing, and user B urgently needs to edit the locked file, and the file is locked by user A, user B can choose to steal the lock and directly have User A who locks the read/write permission of the file becomes user B with permission. That is, the user B sends a replacement request for the user identification information corresponding to the locked file in the cache server, and after receiving the replacement request sent by the user B, the fourth receiving module 114 replaces the module 115. The user identification information of the locked file is replaced with the user identification information of the user B, and the second prompting module 116 generates the prompt information for the user identification information of the locked file to be replaced to prompt the user A.

The file reading and writing device of the embodiment of the present application provides functions such as file locking, file unlocking and lock-up for the user, and solves the problem that the content submitted by the multi-person collaborative development conflicts and covers each other, and uses the cache server at the same time. Saving the lock file can solve the problem of unsynchronized information in multiple WebIDE servers, so that multi-person collaborative development can fully utilize the advantages of fast and environmentally unrestricted.

In order to implement the above embodiments, the present application also proposes a file reading and writing system.

FIG. 8 is a schematic structural diagram of a file reading and writing apparatus according to an embodiment of the present application. As shown in FIG. 8, the file reading and writing system includes: a WebIDE server 1, a cache server 2, and a file server 3.

Specifically, the WebIDE server 1 is configured to receive an access request, and obtain the file identification information and the first user identification information according to the access request, and query the cache file 2 for the lock file corresponding to the file identification information, if not The locked file corresponding to the file identification information is obtained from the file server 3, and the first original file corresponding to the file identification information is obtained, and the locked file is generated according to the first user identification information and the first original file, and the locked file is submitted to the cache. The server 2, and receiving an editing operation for the first original file, and submitting the edited first original file to the cache server 2;

The cache server 2 is configured to store the lock file and update the lock file according to the edited first original file.

In an embodiment of the present application, the WebIDE server 1 is further configured to: when the locked file corresponding to the file identification information is queried, determine whether the first user identification information matches the second user identification information corresponding to the locked file, If the first user identification information matches the second user identification information, the lock file is obtained from the cache server 2.

In an embodiment of the present application, the WebIDE server 1 is further configured to generate prompt information for refusing to acquire the locked file when the first user identification information does not match the second user identification information.

In an embodiment of the present application, the file server 3 stores a second original file, wherein the second original file is an updated version of the first original file, and the WebIDE server 1 is further used to obtain the first file from the file server 3. Second, the original file, and determine whether the first submission information of the locked file in the cache server 2 matches the second submission information of the second original file, and when the first submission information matches the second submission information, the locked file is submitted to File Server 3. The file server 3 is also used to replace the second original file with a locked file.

In an embodiment of the present application, the WebIDE server 1 is further configured to: when the first submission information does not match the second submission information, update the locked file according to the second original file, and update the information according to the second submission information. Submit the information and submit the updated lock file to the file server 3. The file server 3 is also used to replace the second original file with the updated lock file.

In an embodiment of the present application, the WebIDE server 1 is further configured to receive an unlock request for the locked file in the cache server 2, and determine a second user identifier corresponding to the first user identifier information and the lock file. When the information matches, the lock file is deleted from the cache server 2.

In an embodiment of the present application, the WebIDE server 1 is further configured to receive a replacement request for the second user identification information, and replace the second user identification information with the first user identification information according to the replacement request, and Generate prompt information that the second user identification information is replaced.

In addition, the implementation and function of the file reading and writing system according to the embodiment of the present application can be referred to the implementation manner of the file reading and writing method and the file reading and writing device in the above embodiment. To reduce redundancy, no further details are provided herein.

The file reading and writing system of the embodiment of the present application implements a file locking mechanism suitable for the WebIDE system through a cache server, and uses a cache server as a buffer between the file server and the WebIDE server, and uses a cache mechanism to implement the file. Locking, so that the user has the exclusive operation right of the file during the operation of the file, avoiding conflicts between the content submitted by multiple users when operating the same file, so that the WebIDE system can be in multiple collaborative development processes. Play a bigger role. In addition, using the cache mechanism to lock the file is cheaper than modifying the file server's database each time, and the cache mechanism can handle multiple files more flexibly, generate different copies of the same file, and so on. Give users a better experience.

Furthermore, the user is provided with functions such as file locking, file unlocking and lock-up, which solves the problem that the content submitted by the multi-person collaborative development conflicts and covers each other, and the use of the cache server to save the locked file can solve multiple WebIDE servos. The problem of unsynchronized information in the device makes it possible for multiple people to fully exploit the advantages of being fast and not subject to environmental constraints.

It should be understood that portions of the present application can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be implemented with software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented by any one or combination of the following techniques well known in the art: having logic gates for implementing logic functions on data signals Discrete logic circuits, dedicated integrated circuits with suitable combinational logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

In the description of the present specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" and the like means a specific feature described in connection with the embodiment or example. The structure, materials, or features are included in at least one embodiment or example of the application. In the present specification, the schematic representation of the above terms is not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in a suitable manner in any one or more embodiments or examples. In addition, various embodiments or examples described in the specification, as well as features of various embodiments or examples, may be combined and combined.

While the embodiments of the present application have been shown and described above, it is understood that the foregoing embodiments are illustrative and are not to be construed as limiting the scope of the present application. Variations, modifications, substitutions and variations of the above-described embodiments are possible.

Claims (21)

 A file reading and writing method, comprising the steps of: receiving an access request, and acquiring file identification information and first user identification information according to the access request; querying, by the cache server, the file identification information Locking the file, if the locked file corresponding to the file identification information is not queried, obtaining the first original file corresponding to the file identification information from the file server; according to the first user identification information and the first original Generating a lock file and submitting the lock file to the cache server; and receiving an edit operation for the first original file, and submitting the edited first original file to the cache server So that the cache server updates the locked file according to the edited first original file.    The method for reading and writing a file according to the first aspect of the invention, wherein, after querying the lock file corresponding to the file identifier information in the cache server, the method further includes: if the lock file corresponding to the file identifier information is queried Determining whether the first user identification information matches the second user identification information corresponding to the locked file, and if the first user identification information matches the second user identification information, The cache file is obtained from the cache server.    The file reading and writing method of claim 2, wherein, after determining whether the first user identification information matches the second user identification information corresponding to the locked file, the method further includes: If the user identification information does not match the second user identification information, generating prompt information for refusing to acquire the locked file.    The file reading and writing method of claim 1, wherein the cache server further updates the lock file according to the edited first original file, and further includes: Obtaining a second original file, and determining whether the first submission information of the locked file in the cache server matches the second submission information of the second original file, if the first submission information and the If the second submission information matches, the locked file is submitted to the file server, so that the file server replaces the second original file with the locked file.    The file reading and writing method of claim 4, wherein, after determining whether the first submission information of the locked file matches the second submission information of the second original file, the method further includes: if the If the submission information does not match the second submission information, updating the locked file according to the second original file, and updating the first submission information according to the second submission information, and the updated The lock file is submitted to the file server.    The file reading and writing method of claim 1 or 2, further comprising: receiving an unlock request for the locked file in the cache server, and determining the first user identification information When the second user identification information corresponding to the locked file matches, the locked file is deleted from the cache server.    The file reading and writing method of claim 3, wherein after generating the prompt information for refusing to acquire the locked file, the method further includes: receiving a replacement request for the second user identification information, and according to the The replacement request replaces the second user identification information with the first user identification information, and generates prompt information that the second user identification information is replaced.    A file reading and writing device, comprising: a first receiving module, configured to receive an access request; and a first obtaining module, the user acquiring the file identification information and the first user identification information according to the access request; The module is configured to query, in the cache server, the lock file corresponding to the file identifier information, and the second obtaining module is configured to: when the query module does not query the lock file corresponding to the file identifier information, Obtaining, by the file server, the first original file corresponding to the file identification information; generating a module, configured to generate a lock file according to the first user identification information and the first original file; and submitting a module, The locking file is submitted to the cache server; and the second receiving module is configured to receive an editing operation for the first original file, wherein the submitting module submits the edited first original file Go to the cache server, so that the cache server updates the lock file according to the edited first original file.    The file reading and writing device of claim 8, wherein the method further includes: a first determining module, configured to determine, when the query module queries the locked file corresponding to the file identification information Whether the first user identification information matches the second user identification information corresponding to the locked file; the second obtaining module is further configured to: when the first user identification information matches the second user identification information Obtaining the lock file from the cache server.    The file reading and writing device of claim 9, further comprising: a first prompting module, configured to: when the first user identification information does not match the second user identification information, Generate a prompt to refuse to obtain the locked file.    The file reading and writing device of claim 8, wherein the method further includes: the second obtaining module is further configured to obtain the second original file from the file server; and the second determining module is configured to determine the Whether the first submission information of the locked file in the cache server matches the second submission information of the second original file; the submitting module is further configured to: when the second determining module determines the first When a submission information matches the second submission information, the locked file is submitted to the file server, so that the file server replaces the second original file with the locked file.    The file reading and writing device of claim 11, further comprising: an update module, configured to: when the second determining module determines that the first submission information does not match the second submission information Updating the locked file according to the second original file, and updating the first submission information according to the second submission information, wherein the submitting module is further configured to submit the updated locked file To the file server.    The file reading and writing device of claim 8 or 9, further comprising: a third receiving module, configured to receive an unlock request for the locked file in the cache server; and an unlocking module And deleting, when the first determining module determines that the first user identifier information matches the second user identifier information corresponding to the lock file, deleting the lock file from the cache server.    The file reading and writing device of claim 10, further comprising: a fourth receiving module, configured to receive a replacement request for the second user identification information; and a replacement module, configured to The replacement request replaces the second user identification information with the first user identification information; and the second prompt module is configured to generate the prompt information that the second user identification information is replaced.    A data reading and writing system, comprising: a WebIDE server, a cache server, and a file server, wherein the WebIDE server is configured to receive an access request, and obtain file identification information and a first according to the access request. a user identification information, and querying the lock file corresponding to the file identification information in the cache server, if the lock file corresponding to the file identification information is not queried, obtaining the file identification information from the file server a first original file, and generating a lock file according to the first user identification information and the first original file, and submitting the lock file to the cache server, and receiving the first original Editing operation of the file, and submitting the edited first original file to the cache server; and the cache server is configured to store the lock file, and according to the edited first original file pair The lock file is updated.    The file reading and writing system of claim 15, wherein the WebIDE server is further configured to determine whether the first user identification information is related to when the locked file corresponding to the file identification information is queried And the second user identifier information corresponding to the lock file is matched, and if the first user identifier information matches the second user identifier information, the lock file is obtained from the cache server.    The file reading and writing system of claim 16, wherein the WebIDE server is further configured to: when the first user identification information does not match the second user identification information, generate a rejection request The prompt information of the locked file.    The file reading and writing system of claim 15, wherein the file server stores the second original file, wherein the second original file is an updated version of the first original file, The WebIDE server is further configured to obtain a second original file from the file server, and determine a first submission information of the locked file in the cache server and a second submission information of the second original file. Whether the matching file is submitted to the file server when the first submission information matches the second submission information; the file server is further used to replace the second original file with the Lock the file.    The file reading and writing system of claim 18, wherein the WebIDE server is further configured to: when the first submission information does not match the second submission information, according to the second original file Updating the lock file, updating the first submission information according to the second submission information, and submitting the updated lock file to the file server; the file server is further configured to: The second original file is replaced with the updated lock file.    The file reading and writing system of claim 15 or 16, wherein the WebIDE server is further configured to receive an unlock request for the locked file in the cache server, and determine the When a user identification information matches the second user identification information corresponding to the locked file, the locked file is deleted from the cache server.    The file reading and writing system of claim 17, wherein the WebIDE server is further configured to receive a replacement request for the second user identification information, and the second request according to the replacement request The user identification information is replaced with the first user identification information, and the prompt information that the second user identification information is replaced is generated.