Albian development Note 2

I did not work overtime last night. I went home to continue Albian. Two problems were found.

Currently, Albian can easily save data. Albian provides two create reloads: save an object and save multiple objects. No problem occurs when saving an object. data can be accurately saved to the specified database and table based on the route. When saving multiple objects, we tested two types of entities: one order and the other bizoffer. However, when two entities of the same type are saved (for example, two orders ). A problem occurs: the subsequent object data will overwrite the previous object data. I began to doubt whether there was an error when I allocated storagecontext, but I didn't find Debug. I also wondered if there was a problem with the SQL statement. I still didn't find any problem after debug. I can only check it.CodeAnd find that you have made the mistake during modeling. In my original modeling, CMD and paras in storagecontext were stored using the idictionary <string, dbpara []> structure. The idea was: A plain text corresponds to a parameter of its own. In this way, the idictionary structure can meet the requirements. However, if the same plain text structure occurs, a problem may occur, because I have performed the replacement operation, the previous object data will be updated later. In fact, I am stupid, but the structure of CMD-paras is carried by the entity class. Here, I just need to change it to ilist. Refactor the code and use the test case again. No problem.

The second problem is the Albian code structure. At the beginning, I want to create an interface for DML operations, and then perform different operations to implement this interface. However, after reconstruction of the create code, it is found that except for the code of the SQL statement, other codes are identical. In this case, this interface is just a method (such as getsql), and it feels okay at first, but the more you see it, the less pleasing to the eye. Then I thought, is the interface of a method not a delegate? Change all to delegate. Every implementation method is written according to the delegate signature, and then passed through parameters. Isn't there much code left? It also saves the physical strength of the inherited interface. In this way, this part is also changed to commission.

Explanation:

Last articleArticleTo solve the "pseudo distributed transactions" mentioned in. The transaction management used by Albian is a step-by-step operation for each database. This method is indeed risky. The possible cause is that if we have 2 (a, B) operations to submit. After submitting a, submit B. If a network interruption occurs between these two operations (submitted a, is about to submit B) or the machine B is down, then ourProgramThe transaction will be rollback. But for a, the Operation has been commit, and has become permanent storage and cannot be rollback, so dirty data appears in our system. In this case, we can remedy the problem based on the situation. For example, after saving, we can determine whether the operation is correct. If the operation is incorrect, we can execute a remediation code. However, this is not required for general systems. Similar to the operation problem, it can only happen in a distributed system. For distributed systems, the CAP theory for a single node is no longer applicable. You must discard any of the CAP features to meet the remaining two features. What Albian gives up is consistency. In fact, when you analyze the transaction sectionSource codeIt is easy to conclude that we use "final consistency" to ensure data integrity. In distributed systems, data integrity is generally less demanding, at least not 100%. The height may be 99. 99%, the lower may be 95%, or even lower. Of course, these metric data is only for the data integrity of a period of time (such as a database access or a user access to the system, finally, we will achieve data consistency in the system through external methods such as replication and synchronization.

For the use of CAP theory in Distributed Systems, please G!