Infoblazer – Pure Java Performance

After several years of work, the latest release of the XX Framework is now available.

The major change to the framework is that it is now ported to SpringMVC. This should allow greater flexibility and easier incorporation into existing or new Spring applications.

One of the first comments I heard when I released the framework back in 2006 was “how does this differ from Spring”. I didn’t think it was much like the Spring core, but he must have meant SpringMVC. Over the years, Spring MVC turned out to be one of the few frameworks that made perfect sense in almost every manner (as does Spring itself). Much of the early work on XX, and most frameworks, is in developing the plumbing (servlet routing, data marshalling, transactions, security, etc). This was all built into XX, but Spring already does it and much better I am sure.

A while back, I made the decision to port the framework to sit on top of SpringMVC and let it handle all the plumbing and let XX do what Spring does not: automatically marshall data from the web layer to the database layer and back, and provide an XSL centric view paradigm.

The migration was surpisingly smooth and would have happened much sooner if I can the time or additional resources. After the servlet mapping layer was migrated, most of the XX controller and database functionality just worked as is. The one main change I made was to incorporate Spring Hibernate integration (DAO stuff) and dependency injection.

The framework has powered Domuswap.com, in both its Spring and pre-Spring incarnations. While a site’s performance is certainly related to the hardward available, we did get some 4000 visitor days at its peak.

I still think the key differentiators of the XX framework continue to be valuable. Further integration into Spring is needed to where it is more of a plug in to Spring rather than a separate framework built on top of Spring (like Grails).

Check out the XX Framework.

I am reprinting this older blog post on Caching in the XX Framework. It is still relevant, though I would prefer to get the basic documentation up first.

The following discussion example uses guestbook sample, on the XX framework web site. http://xxframework.org/guestbook/ListGuestbook. This non-cached page will be converted into a cached implementation.

Let’s look at the structure of the page displayed when the URL listed above is requested.

The page is divided into 5 components. This can be best illustrated by looking at the XX config file.

ListGuestbook.xml

Referring the guestbook page (http://xxframework.org/guestbook/ListGuestbook), the 5 components implement the following functionality

The other components of the page (top menu and header graphics) are included in the JSP page indicated in the config file (searchlist.jsp). Note that the JSP page can include dynamic and well as static content. In this case, the content is static.

The caching behavior is described by the “scope” attribute of the class element. The valid scope values are the following:

Since all classes have page scope, no caching takes place in the ListGuestbook servlet.

If the 5 classes above, classes 2, 4, and 5 can be cached at the application level, since all users should see the same text when browsing this page. Classes 1 and 3 are user specific. Class 1 section will change from a login to a logout button depending on the logged in status of the user.

Class 3 may not be that obvious. While not really necessary, the author text box will default to the user’s user id, if logged in. If not logged in, author text box will maintain any previous value entered by that user. For a logged in user, this information is available in the XML request document. For a non-logged user, this information is maintained in the user’s session. Therefore, for classes 1 and 3, session level caching is appropriate.

To implement the caching needed, modify the scope attribute of the class element, as follows.

The class element may also take an optional “timeout” attribute. The value of this attribute represents the time, in milliseconds, when the cache should automatically be expired.

Given a config file as above, classes 2, 4, and 5 (application level) will only be called once. Afterwards, the html values will be read from application memory (servlet context actually). Classes 3 and 5 will be called once for each user. Afterwards, the values will be read from session memory.

Leave the system in this state, however, will cause a potential problem: once generated, the pages will never change. This is not a problem for classes 2 and 4. These sections will only change when the menu for search box changes. In our case, these sections are static. If our search box contained a company pull down, for instance, the search section would need to be updated whenever a company is added or deleted.

The other page sections, however, will not remaining static. Most obvious is class 5, the message list itself. This will change whenever a message is added or deleted. Since deletion is not part of the guestbook sample, let’s consider the case when a message is added. If the cache is not updated, the new message will not show up. To fix this problem, we must look at all the use cases that could cause the cache to need to update. In the case of the guestbook application, the add message use case will invalidate the saved message list.

The add message use case is implemented by the SetMessage servlet servlet. This servlet uses the SetMessage.xml XX config file. Here is the relevant portion of that config file

SetMessage.xml

To control caching we add a “cache_control” element.

SetMessage.xml

This new element states that when this class is successfully executed, clear the cached values for the indicated pages, represented by the XX config file name and class id within the config file.

In the case of the SetMessage use case, class 5 in the ListGuestbookCache config file (the message list) is cleared. The next time the ListGuestbookCache page is called, the message list will be regenerated.

The remaining two classes in the ListGuestbookCache use case are session level caches. The first, class 1 changes when the user logs in or out. Therefore, we can clear the cache for that class on the login and logout use cases. These use cases are represented by the Logon.xml and Logoff.xml file. The appropriate cache_control elements are added to these two configurations

Logon.xml

Logoff.xml

Returning to the ListGuestbookCache use case, class 3, the add message area, hasn’t yet been handled. This text box needs to change when the user adds a message, or when the user logs in and out. Therefore, we need to clear this case on user login/logout, and on add message. This can be accomplished by adding a cached_page element to the existing cache_control element. The following changes complete our requirement of clearing the cache in the appropriate situations

SetMessage.xml

Logon.xml

Logoff.xml

Additional notes on Caching

In addition to the class id and scope, caching is specific to the parameters of a given request. For a show user user case, we would not want showuser?id=6 to use the same cache as showuser?id=7. But we would want all calls to showuser?id=6, executed by any user, to use the cached result.

Internally, XX uses the request parameters to distringuish the two so the appropriate result is returned.

I’ll have more information in the next few days, but I’ve uploaded all the files to Sourceforge.

These files include the actual framework source , in Jar form and in the form of a simple Hello World Web App. I also updated the two demo programs, Guestbook and Petshop.