Transaction isolation (Transaction Isolation)
n islation is the i in the ACID principle, meaning that you will be separated from different users of the same database. You can get balance between performance and security by specifying the isolation level. A total of four isolation levels:
l The read uncommitted: Do not do any isolated and has the highest performance;
l The read committed: Can solve the problem of Dirty Reads; this isolation level is a lot of database default isolation levels, such as Oralce and SQL Server.
l The REPEATABLE READ: Solve UnrepeAtable READ Questions; First, First, User A reads out of data X; then, user B changes the data x; user A rereading data x, resulting data, and first inconsistent.
l The serializable: Solving the PHANTOM (phantom) problem, the feature of this problem is: First, the user A queries the data; then, the user B adds data x; user A queries data again, the result data and the first time inconsistent. Be very careful when using this isolation level, you can do a test: Set all your actions to this level, soon you will see the database is getting more and more slowly. And the transaction is very difficult to detect.
n How to specify the isolation level in EJB? In Bean-Managed Transaction, use the Connection.SetTransactioniSolation () method; in the transaction of the container management, you cannot use deployment descriptor to specify, but specify by the above API or through the DEPLOY tool and database. Why can't you use deployment descriptor to specify? According to Sun's people: "For system providers, it is very difficult to assemble the component level implementation."
n If there are different databases in the same thing, different isolation levels can be specified. However, it is usually specified as the same isolation level for the stability of the program.
Distributed Transaction
n Two paragraph submission (Two Phase CommTocol or 2PC): The basic principle of distributed transaction implementation.
u First step: Send the Before Composit Manager to all resource manager involved in the entire transaction, at which point the resource manager abandon submitted final time. If any resource manager is abandoned, the entire transaction will be canceled. Otherwise, the transaction will perform in the steps until the error occurs. All updates are recorded in the transaction log to prevent errors.
u Step 2: Only after the first step is not canceled, in this step, all databases are real data update operations.
n There are many transaction manager in distributed transactions, one of which is called coordinator, which is used to coordinate other transaction managers on the network, which is:
The U Coordinator sends PrePared Commit information to each transaction manager;
u Each transaction manager forwards this message to its corresponding resource manager;
u Each transaction manager forwards the information returned by the Explorer to the coordinator. If each transaction manager agrees with Commit, the coordinator record log is not tested;
U Finally, the coordinator notifies each transaction manager for submission, and the transaction manager notifies the corresponding resource manager in order, and he writes data for a long time. If an error occurs, use the log of the previous coordinator to record error recovery.
N Transaction Communication Protocol: The transactional communication protocol is used to communicate with each other in the transactional manager involved in distributed transactions. IIOP is such an agreement.
n Transaction Context: The most important information in the transaction communication protocol is the transaction context. He is an object that includes the current state of the system. View this context, you can learn: Do you have a business current status and other useful information in your business. For the thread of the components in a transaction, it must have a transaction context.
N J2EE specification, but not required to require server vendors to achieve the above-mentioned transaction context interactive mechanism, so different manufacturers' APP servers cannot guarantee the distributed two paragraphs.
Design transaction session in EJB
The n app server helps us have made a lot of transaction control, but this is just half, but also do some processing in the program. When the transaction is canceled, you have a variety of options, you can terminate logic processing and throw an exception to the client; you can also retry the transaction multiple times, but you will end the program logic after multiple retry failures. For unspecited session beans, things are simple, as long as the exception is thrown to the client; but for the state SESSION bean, there is still a status value with the customer's communication in memory, and the app server It is not possible to save these status values for you, but it will give you a chance to let you save these values, as long as your bean implements the sessionsynchronization interface. The way you have to implement in this interface is:
u afterbegin (): Before the transaction is started to be called by the container; at this time, the transaction has just begun, you can read some of the data you want to cache from the database;
u BeforeCompletion (): Before the end of the transaction is called by the container; at this time, the transaction will end immediately, you can write the cache data to the database;
u aftercompletion (boolean): Call is called after the end of the transaction. The most important thing for rollback operations is this method. The container will call this method after the end of the transaction regardless of whether the transaction is submitted or canceled. You can know if the transaction is submitted through this method. If you are false (ie, the transaction is canceled), you should handle the session status value in this method. Note: The mentioned transaction here must be controlled by the container, and cannot be program control.
