Javazoid Links

Javazoid updated Sept 1 2001

Home of

In Feb 2000, my Java IDE FrenchRoast won honorable mention in the 2nd JavaWorld CodeMasters series.

About Javazoid

Gervase Gallant Resume
Downloads...

Articles
WordFind applet
IO,IO...
Wizard...
Date Chooser...




Oct 2000
Below is a work in progress... a version of Minesweeper. You could also win a million bucks playing Minesweeper.

Cache


building a simple object cache...
Someone I work with suggested that implementing an object cache would be a difficult and bug-prone endeavor. I thought it should be straightforward. As I saw it, the basic implementation of an object cache should meet these requirements:
  • the Cache should be a singleton object because in all likelihood it would be a major resource hog and callers should not be able to create more than one.
  • the Cache requires a timeout mechanism and some functionality to clear itself on a regular basis.
  • the Cache should be threadsafe.
  • it should allow users to add, get and remove items.

    The package com.javazoid.cache consists of 4 classes:
    Cache - A decorator for a hashtable, which would allow the developer/user to add, remove and get items. The constructor for this class is private and so the only way to create an instance is to call the static createCache() method, which returns the one and only instance.
    CacheItem - Basically, another wrapper for the object that is to get inserted into the Cache. The CacheItem provides a timeout field, which is about the only reason this class is required.
    CacheManager - A kind of visitor object that gets created when the Cache itself is created. This object lives on a separate thread and spends most of its life asleep. Occasionally it wakes up and throws old objects out of the Cache.
    CacheTest - My belief is that no component or package should be created without some capability for testing. This type of class also allows the developer to get a feeling for the robust nature of the component -- in other words, how much more testing is required before the component is production-worthy.


    Challenges
  • To avoid memory leaks. The CacheManager can be a cause of a huge resource leak if 1) the developer can instantiate many cache objects and 2) there is no way of shutting down the Manager. I dealt with the first item by ensuring a Singleton object.
  • The second challenge is dealt with by the Cache clear() method which nulls out the Manager's internal hashtable. When the Manager discovers there is no data to work on, it quietly stops. I felt this was better than calling the thread's stop method, although it has the side behaviour of not shutting down immediately, since the call to clear the cache will in all likelihood be made while the thread is sleeping.

    Download source

    Any questions, please contact me ggallant@bigfoot.com .


    Copyright (c) Gervase Gallant 1999,2000,2001.