# tco-blog design overview
Contents
Overview
This page provides a hodge-podge discussion of various aspects of the blog's design. It's unlikely to be of any interest unless you're looking through the code, in which case it may explain a few things. I intend to add extra sections to this document as and when the need or urge arises, which is likely to be when I revisit a piece of functionality and can't remember how it works!
First off, I used tco-blog to teach myself J2EE development, and it shows. For a while, it was home to some weird and wonderful tinkering. At one time it had its own Connection pooling, which didn't last long, thankfully. Reviewing the code early in 2007, I came across about 3 different naming conventions that marked my slow progress as a Java developer. Thank heavens for Eclipse's refactoring functionality.
What it also means is that while some things are a little naive or convoluted, it's mostly kept simple because I lacked the sophistication to do anything else.
Two Applications
Tco-blog comprises two separate web applications, using a common database. The front-end app is in the 'blog' project, and is a pure Servlets and JSPs affair. The back-end app, 'blogadmin', uses Struts, but not always diligently.
For a while the admin and front-end functionality were in one web app, but I decided to separate them because (a) I had the daft notion that if I was running in a memory-constrained environment I could shut the admin app down when I didn't need it, (b) I knew I could change one app without breaking the other, and (c) it would allow me to use a completely separate admin interface if I ever wanted to.
The two apps share a smidgeon of DB-related code, which is stored in the blog-db project.
Database Layer
Everything is stored in a MySQL database. The database design itself carries some baggage from my original Notes app, and some fields and structures could have been done differently if I'd started out clean. This is also largely why the app doesn't enforce foreign key relationships. Another reason is that I wavered between using MySQL and PostgreSQL for a while, but finally settled for MySQL, where even the NOT NULLs in the schema are kinda pointless.
The app uses direct JDBC calls for all database interaction, and uses typical J2EE-style DAOs to do it. The DAO layer isn't as neat and straight-forward as I'd like it: it's not always easy to tell which DAO should be doing what. Also, the DAOs don't do strict CRUD functionality, and have numerous methods which directly touch and modify certain fields. This could be a good or bad thing depending on your point of view.
If I was inclined, the one smart change I could make would be moving the data layer to Hibernate. I've never done it because it works well enough, I like having the opportunity to work with raw JDBC, and I just can't be bothered to change it.
On the subject of Hibernate...
Caching and Performance
Tco-blog is fairly lean. I had initially expected the app to run on a virtual server with 64MB of memory. As a result, I was extremely wary of storing things in memory.
The front-end app caches frequently re-used data, such as the RSS feeds, some images and css files, and side panel components. Posts themselves aren't cached though, which is a shortcoming. The app would have a much higher capacity if they were, but for my kind of traffic it's not an issue, and the few load tests I've done happily handled a few dozen users on a dodgy old 1GHz server.
In retrospect, it was pointless, but the blogadmin app caches neither data nor objects, and tries to leave as much available for garbage collection as possible. The overhead of setting up DAOs and the like is minimal given how infrequently the application is used, so I've been in no rush to change it.
Inter-app communication
Changes on the back-end are propagated to the front-end by means of a database table, db_state. When the back-end application writes changes to the database which will affect the front-end, a flag is written to the db_state table. The front-end implements a simple Observer mechanism. A thread polls this table periodically, and if the flag is set, notifies all objects which have registered themselves as DbState observers. They can then reset caches and do whatever they need.
The table could allow for more fine-grained notification, but at present, any state change causes all front-end objects to reset themselves. Given the low loads, I haven't found this to be a problem.
Plinks
The app allows two types of entries: blogs and static articles. Each is identified by a permalink (perm_id in the database), but referred to as 'plinks' in much of the code. The two main differences between the two types of entries are firstly, a blog entry has its permalink autogenerated as a time-stamp, while static entries have editable permids, and secondly, blog entries form part of the summary pages and RSS feeds, while static articles don't (*).
The app tries to find an entry for anything you try to access in the /plink subdirectory. Every entry's perm_id is the part of the URL coming after the /plink bit. A blog entry could have a plink of 2007/03/05/070305-2234.html, which creates the impression of data being stored in directories - but it's just an arbitrary string. Static articles can also have fake subdirectories.
Why do I do this? I can envisage a time when I want to archive entries into real on-disk HTML pages. The current structure would allow that without breaking permalinks. That's why I've eschewed the common approach that many blog applications take of specifying the plink as a request parameter: that would require parameter-parsing logic in perpetuity.
(*) I seem to recall that this was an idea I took from the popular Lotus Domino-based Blogsphere blog app, which heavily influenced the design of my own Domino-based blog, which was also something of a teach-me-web-dev exercise at the time.
Last modified: {2007.03.06 00.18}
all posts