1. Overview In web applications, some reports can be generated for a long time to calculate; some websites provide weather information, it needs to access the remote server for SOAP calls to get temperature information. All of this is an example of complex information. Excessive complex information in the web page may cause the web server, the database server load is too heavy. The JSP code block buffer brings free to add a variety of complex information to developers. JSP can encapsulate and run complex Java code in tag library, which makes JSP page files easier to maintain, making non-professional developers using JSP page files more convenient. There are already many tag libraries, they or commercial products, or source code open products. However, most of these products are only implemented in the form of a tag library. They have the functions that can be implemented with a simple Java Scriptlet. There are very few products that use custom tags in a creative way, providing almost the JSP custom marker. Usage of impossible implementation. The OSCache tag is designed by OpenSymphony, which is a groundbreaking JSP custom tag application that provides fast memory buffering features within an existing JSP page. Although there are already some suppliers to provide various forms of cache products, they are all productive for specific suppliers. Oscache can run on any JSP 1.1 compatible server, but can not only buffer existing JSP blocks, but also buffer in units of users. Oscache also includes advanced features that increase scalability, such as buffering to disk, programmable buffer refresh, exception control, and so on. In addition, as OpenSymphony's other products, the code of OSCache is also available for free under an open source license agreement. This article uses a virtual auction website design process as an example, introducing the work of OSCache. This imaginary Web site will include: a recent management page recently auction activity; a feature is complete, home page with various promotional information; a special navigation bar, which contains all users who have not yet traded auction activity information. Second, the management page Auction website contains a management report, and the database server takes a few seconds to create such a report. This is important because we may make multiple administrators monitor the system operation, and they want to avoid administrators to regenerate this report every time you visit. In order to achieve this, we will package the entire page into an application-level buffer mark, which is refreshed every 1 hour. Some products from other suppliers have similar functions, just Oscache is better than they do. For the simplicity, we will not pay more attention to format issues. When writing a management page, we first join the tag library declaration to the page: <% @ Taglib URI = "Cachetags" prefix = "cache"%>
Next we have to use the Cache tag to surround the entire page. The default buffer time of the Cache tag is 1 hour.
Now the management page has been buffered. If the administrator accesses the same page again within an hour after the page is generated, he will see the previously cached page, which does not need to generate this report again by the database server. Third, the home page of the home page shows the site activity, promotes those auction activities that are about to end. We want to show the number of active auction activities, the current login user, in the short term, the list of auction activities, and the current time. This information has different time accuracy requirements. The auction activity on the website usually lasts for several days, so we can set the number of buffer effective auctions to 6 hours. The number of users is obviously more frequent, but here we will buffer this value for 15 minutes each time. Finally, we hope that the current time displayed in the page is always a precise page access time. After declaring the tag library in the home page, we first directly output the current date with without buffering: <% = new java.util.date ()%> Next, we have to display a list, list those will Auction activities ending in the short term: <% // Constructs an item Iterator Auctions = .... While (Auctions.haSmore ()) {Auction Auction = (Auction) Auctions.next ();%>
Finally, we want to show the number of active auctions, this number needs to buffer 6 hours. Since the cache tag requires the number of buffer data, we convert 6 hours to 21600 seconds:
It can be seen that we only constructed a homepage with a complex buffer system with a small number of code. This buffer system buffers each part of the page, and the buffer time of each portion is fully compliant with their respective information changes. Because there is a buffer, we can now put more content in the home page; and in the case where there is no buffer, the contents of the homepage will cause the page access speed to slow, and may even bring the database server. Overweight load. Fourth, the navigation stripe assumes that when the website is planned, we decided to display the contents of the shopping cart below the left navigation bar. We will show the number of bids and current quotes for each item aurated by the user, as well as the list of goods that have the highest price in the current user. We use the session-level buffer capabilities to construct the above function in the navigation bar. Put the following code into the template or contain file so that other pages in the website reference this navigation bar:
Here we introduce two important properties, namely Key and Scope. In the code in front of this article, since the Cache tag can automatically create unique keys for the code block, we do not need to manually set this Key property. But here, we want to reference this buffered code block from the rest of the website, so we explicitly define the Key property of the Cache tag. Second, the Scope property is used to tell the Cache tag that the current code block must be buffered in units of users, rather than buffering all users. It should be very careful when using the session level buffer, it should be clear: Although we can reduce the complex navigation bar by a double or 10 times server load, it will greatly increase the memory space required for each session. The increase in possible concurrent users in CPU is undoubtedly ideal, however, once the number of concurrent users is reduced to the CPU, this solution is no longer ideal. As mentioned earlier herein, we hope to reference this buffered code block from the rest of the website. This is because when a user adds a product for auction, or when bid bidding for goods for other users auctions, we want to refresh the buffer, so that the navigation strips have the latest content when they are read. Although these data may change because of other users' activities, he may be very confused if the user has not changed after performing an action on the website. The Flush marker provided by the Oscache library can refresh the buffer content. We can add the following code to the page that handles user action and may affect this area:
