Expiring Data with Hashbelts
In this article I will show you how to use the hashbelt
algorithm by using two distinct examples: implementing session
keys and reimplementing the RemoteStubCache class from my
previous articles on command objects in RMI. By the end of this
article, you should feel comfortable using hashbelts in your
code and understand when it is appropriate to do so.
Introducing Automatic Data Expiration
Developers building frameworks or distributed programs (or frameworks for distributed programming) face challenges that are somewhat different from those facing developers building stand-alone applications. One of the more interesting problems is simply trying to find simple and convenient algorithms for determining when data and object references are no longer valid or need to be refreshed. The difference between data your application owns and data that originates in, and is changed by, someone else's code (possibly running in a distinct simultaneous process) is enormous.
The Hashbelt Data Structure
In the first article in this series, I explained why it is sometimes necessary to expire data, and discussed the standard approaches for doing so. This article focuses on a particular algorithm for data expiration that I have taken to calling a "hashbelt." (The name is a combination of "hashmap" and "conveyor belt.") Hashbelts are a generic data structure that can be easily adapted to a wide variety of problems involving time-sensitive data. They are easy to use, simple to extend, and quite efficient.
Network Magazine Provides information Technology (IT) and network managers with strategic analysis, views of emerging technologies and product reports....
subscribe now
