Multi-threaded and transaction
Author: gnicky URL: http://blog.9cbs.net/loconfuse/
"In practical problems, don't do any main work in the event handling thread, but should use additional threads as a working thread and allow the event processing thread to return to the processes waiting state." This sentence seems very reasonable, and the advantages of multi-threaded are fully reflected! So how to divide the thread processing work and how business is going to process?
In fact, this problem can be summed up to control the process management coordination of the drive system and the business logic layer, and the concurrency of the transaction is focused on the OOD phase, that is to say, the overall process must be taken into account during the OOD. Multithreaded problem, thereby joining transaction concurrency control.
Simple description The abstract picture is as follows: Look at the recommended skill: "The GUI event processing code should be relatively short, let the event processing thread get back from the processor, and ready to process the next triggering event, if you have to perform a longer task, Work should be passed to another thread for processing. This helps to keep the user interface in activation status and highly sensitive "
This recommendation seems to be very reasonable, but the thread takes the thread, when the button presses, the process database update is handed over to another thread processing, the user interface is activated, the user will press the delete button again, call other data modification The code of the data, the result of this execution and the user expect, may be inexplicable for the user.
For a single machine and a program that can only run in order, in order to reflect multithreading skills, it is necessary to implement concurrency support for data processing transactions, and the cost is also considered.
Therefore, the so-called techniques are also suitable for local conditions!
If there is a wrong point, please leave a message to finish!
