Java Theory and Practice: Understanding jts― balance Security and performance

In the 1th and 2nd parts of his series on JTS, Brian tells the basics, including what a transaction is and how the Java container makes the transaction service transparent to the EJB component. Although the ability to specify transactional semantics of components in a declarative way rather than programmatically can greatly enhance the flexibility of configuring enterprise applications, making improper decisions when assembling an application can weaken application performance and stability. In this final installment, Brian discusses the tools that Java EE provides to manage transaction partitioning and isolation, and some guidelines for using these tools efficiently. Please click on the discussion at the top or bottom of the article to share your thoughts on this article with the author and other readers in the discussion forum.

In part 1th of this series ("An Introduction to Transactions") and part 2nd ("The Magic Beind The scenes"), we define what is a transaction, enumerate the basic characteristics of the transaction, and explore How the Java Transaction Service (Java Transaction Service) and the EE container collaborate to provide transparent support for transactions to the EE component. In this article, we will discuss the division and isolation of the transaction topic.

The responsibility for defining transaction partitioning and isolation attributes for EJB components is borne by the application assembler. If these properties are improperly set, they can have serious consequences for the performance, scalability, or fault tolerance of the application. Unfortunately, there is no rule that must be followed to properly set these properties, but there are some guidelines that can help us find a balance between concurrent and performance hazards.

As we discussed in part 1th, transactions are primarily an exception handling mechanism. The purpose of a transaction in a program is similar to that of a legal contract in a day-to-day business: if something went wrong, they could help recover. But since most of the time there is no real error, we want to be able to minimize their overhead and the rest of the time. How we use transactions in our applications can have a significant impact on the performance and scalability of the application.

Transaction Division

The Java EE container provides two mechanisms for defining the starting and ending points of a transaction: bean-managed transactions and container-managed transactions. In a bean-managed transaction, you explicitly start and end a transaction in the Bean method with Usertransaction.begin () and Usertransaction.commit (). On the other hand, container-managed transactions provide more flexibility. By defining transactional attributes for each EJB method in the assembly descriptor, you can specify the transactional requirements for each method and let the container determine when to start and end a transaction. In either case, the basic guidelines for building a transaction are the same.

Come on, get out.

The first rule of business division is "as short as possible". Transactions provide concurrency control, which usually means that the resource Manager will represent you to the lock of the data item that you access during the transaction, and it must hold the locks until the transaction ends. (please recall the acid characteristics discussed in part 1th of this series, where "I" of "acid" stands for "Quarantine" (isolation). In other words, the result of a transaction does not affect other transactions that are executed concurrently with the transaction. When you have a lock, any other transaction that needs access to the data item you are locking will have to wait until you release the lock. If you have a long transaction, all of those other transactions will be locked and your application throughput will be significantly reduced.

Rule 1: Make the transaction as short as possible.

By making transactions as short as possible, you can increase the scalability of your application by minimizing the time it will take to block other transactions. The best way to keep a transaction as short as possible is, of course, not to do anything without time-consuming in the middle of the transaction, especially to not wait for user input in the middle of a transaction.

It may be tempting to start a transaction, retrieve some data from the database, display the data, and then ask the user to make a choice while still in the transaction. Don't do this! Even if the user is focused, it takes a few seconds to respond--and it's a long time to have a lock in the database for a few seconds. What happens if a user decides to leave the computer, perhaps to have lunch or even go home for a day? The application will have to be forced to stop. Performing I/O during a transaction is a recipe for disaster.

Rule 2: Do not wait for user input during a transaction.

Put the related actions together

Because each transaction has a small overhead, you might think it is best to perform as many operations as possible in a single transaction to minimize the overhead of each operation. But Rule 1 tells us that long transactions are bad for scalability. So how do you minimize the trade-off between the cost and scalability of each operation?

We set rule 1 to be logically extreme--one operation per transaction--which not only leads to extra overhead, but also compromises application state consistency. Suppose the transactional Resource Manager maintains consistency in application state (recall part 1th, where "ACID" "C" stands for "consistency"), but they rely on the application to define the meaning of consistency. In fact, the definition of consistency we use when describing transactions is a bit slick: what the application says about consistency is what it means. The application organizes changes in several sets of application states into several transactions, resulting in a defined (by definition) consistency of the application's state. The resource manager then ensures that the application state is restored to its most recent consistent state if it must recover from the failure.

In the 1th part, we give an example of transferring funds from one account to another in a banking application. Listing 1 shows the possible SQL implementation of this example, which contains 5 SQL operations (one selection, two updates, and two inserts):