OK. I use the null object pattern when I don't want to continually go remote or to a database or to a webservice for data that doesn't exist.
For instance, let's say that I'm building an client to an air shopping service that runs in a different system (different db, org unit, etc.). I get back city codes that I then need to decode--translate into a city name or a city id in my database. Sometimes I might get back bad city codes or codes that don't correspond to cities in my db. There are other cases that are more acceptable than cities, such as equipment codes. I don't want to keep going from the local to the remote cache and then to the database looking for the decoded values for stuff that doesn't exist. I could see the same value 1000 or more times in a single shop response. I wouldn't want to keep doing 1000 extra queries for nothing for every shop. That would be awful. Bad data or a missing item could take down the system at high loads. The solution is to put a special object in the cache that represents a Null Object. Rather than putting in a global null object, I put in a special instance of the type of object that I'm caching in that region. I don't want to mix types in the collection. So, when I get an item out of the cache I check to see (1) if it is equal to the null instance. If so, I return null. (2) If it is null, then I know that I haven't seen it before and I should try the database. (3) If it is not null and not equal to the null instance, I return it. The cache cannot do this for you. This has to be done programatically at the cache client. I have a layer in my application stack that handles caching. I develop service in these layers, which also correspond to separate projects (i.e. separate artifacts). Clean project layers and SOA make for a very nice system. In my current app I have over 20 deployable application projects (collections of services) that all run in their own Tomcat instances (6 or so to a machine) and around 30 projects in total (10 or so are non deployable), all built and managed using maven and wired together with Spring (only using the bean factory). Every web service has these layers and more: REST Service Controller (http into the framework; XML response generation via velocity or jibx; calls the logical service to do the real work; this lives in a deployable application's project) | v Logical Service (can talk to multiple services and managers) | V Manager (Caching Facade; can talk to only one DAO and no other managers; transforms objects from DAOs to local return types) | V DAO (direct sql) or Web Service Client (velocity request generation; jibx parsing) The Null Object pattern is implemented in the manager layer, since that is the only place where caching occurs. Cheers, Aaron --- Enrique Rodríguez Lasterra <[EMAIL PROTECTED]> wrote: > i will try to explain it, but my english is not as > good as it should be :-( > > I want to use JCS on my SDO/jsr235 persistence > system. When i make a > "select * fro table where primaryKey = X" o could > get a table row or > not, but i want to store the result on the cache. > > If I repeat the select, i want to check if JCS has > the table row > stored on it by its primaryKey. If it is stored, but > its value is > null, it should response with null and it should > counted as a hit > count, becouse null is the value i put on the cache. > > if the cache does not kave the primaryKey stored, i > should get the row > from database. > > So, from my point of view, is not the same store > null values or leave > cache without nulls. > > We the workaround, everything run perfectly but the > stats of > hitCount/missCount aren't real. > > Regards, Enrique. > > 2006/10/7, Thomas Vandahl <[EMAIL PROTECTED]>: > > Enrique Rodríguez Lasterra wrote: > > > Hi al, thanks for the workaround, is a good > idea, but i think that a > > > cache should have null values. > > > > What for? When I try to get some object for a key > that does not exist, I > > get null anyway. And (responding to your next > posting) yes, this is > > indeed a cache miss which should be counted as > such. > > > > Bye, Thomas. > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > -- > _______________________________ > Enrique Rodriguez Lasterra > lasterra AT javahispano DOT org > http://www.javahispano.org > Asociación sin ánimo de lucro sobre java > Spanish non profit association about java > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
