TheoryCraft - Breaking down elements into blocks

So I have been doing some more research about Oracle - Database-assisted Web Publishing using Java Stored Procedures from my last post and I've tried to implement it into more manageable chunks.
I mean, you can save processed data (data that has already been calculated and/or had some business/application logic applied to it) in the WebCache and then re-use it instead of contacting the database over and over again. The theory here is sound, but even in the white papers on the subject, there has been some reluctance about whether the cache hits will benefit the overall performance or hinder it.


The Downside of Caching

From my experience, its sometimes impractical to save processed data. For example in a hotel reservation system (and forgive me if I keep using examples from my last company):
The user did a search for all the hotels in a certain area, that have room for 2 adults and 1 child, on the dates of 20/02/2008 and 25/02/2008 and they want to have breakfast included. So as you can see the items in bold, there is a very very low chance that another person might make the same search for the same area, people, start date, end date and rate (breakfast included).
Saving the searches do not make any sense and it would be faster to keep querying the database and processing the data each time. Rather then saving the searching and counting on cache hits to save time.


Oracle's WebCache Idea

So what WebCache is saying, that some processed data should be processed before the user asked for it and when he/she does ask for it, its already prepared. This can be done when there are changes to certain records. Triggers that operate when these records are changed, to update the WebCache ahead of time.
This makes great sense to me. In fact, I can say that there are some things that change very infrequently and here, going to the database constantly makes far less sense.


The Trade Off

So you need to know when to cache and when not to cache. Here is something from Oracle:

Typical applications include product catalog, price list, rate engines, etc where product information, price, rate that are not subject to frequent changes but can be changed by other applications. However, if the events (updates in the database) occur more frequently than the client's requests, this approach creates even more overhead on the server than the traditional request-driven publishing.

Using this Idea in my Project

If you haven't read the main idea and the feature list, please do :P

Now I was and still am, looking into ways of using the database to assume some of the application logic for my website game. I was thinking about using this WebCache idea, but I was confused about how to. What I decided is to break down the interface(web pages) into elements. Then I would find dynamic elements, that need data from the database and try to have them entirely processed in the database and cached there, in a memory table to simulate WebCache (although it still involves connecting to the database which is a bit missing the point of it).

This basically involves taking data, weaving it with html code (in this situation) and saving it as cache to be called by the user ahead of time.
This way, I am abstracting things into blocks and dealing with them directly. I bypass the data stage, when considering caching and only think about updating elements if there were any changes to records in the database.

I got this idea from Java Server Faces and the way Jakarta Struts handles forms. It seems to me that you need to abstract some things and not keep reinventing the wheel with regarding to forms and lists and connecting-mapping them to the database.

So here is an (bad) example of a web page for my project. This is where users can communicate simply with other members in their "SpyNet".

Breaking it down to blocks..

So as you can see, I can take these blocks, process them and keep them in the cache of my memory table. In the example of block 1 and 2, if a member of the user's "SpyNet" turns from offline to online, the database could update these blocks when the user came online and triggered the update in the database. Then when the user refreshed the page, there would be no need to process this information, because its already prepared.


Conclusion

So as the post title suggests, this is theorycraft and has not been tested or applied. I am interested in the "abstracting" nature of this idea and will update my blog if it proves to be a good or bad idea.

Thank you for taking the time to read my blog.