aspose file tools*
The moose likes I/O and Streams and the fly likes backup  hashtable Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » I/O and Streams
Bookmark "backup  hashtable" Watch "backup  hashtable" New topic
Author

backup hashtable

Annekee Dufour
Ranch Hand

Joined: Nov 04, 2003
Posts: 41
My application uses a hashtable to store important information. We want to make a backup of this hashtable on the filesystem every 5 minutes. My plan is as follows:
1. clone the hashtable
2. write the clone to a tempfile using an ObjectOutputStream
3. move the tempfile to the real backupfile
ad 1. I do this because I am afraid that the hashtable might be rehashed while I am writing it to file (it can grow rather fast). Is it indeed necessary? According to the hashtable.clone javadoc cloning a hashtable is 'relatively expensive'. How expensive? Relative to what?
ad 2. Is an ObjectOutputStream a good idea (so easy to write but is it fast and safe?), should I use buffering or something?
ad 3. I do the tempfile-and-move thing to make sure that when the application crashes (or when someone uses 'kill -9'), I will not end up with half an object. Good idea or unnecessary?
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
ad 1. I do this because I am afraid that the hashtable might be rehashed while I am writing it to file (it can grow rather fast). Is it indeed necessary? According to the hashtable.clone javadoc cloning a hashtable is 'relatively expensive'. How expensive? Relative to what?
Sounds like a good idea. The clone() method will be slow compared to an individual put() or get(), but fast compared to the writeObject() method of ObjectOutputStream. So a "quick" clone() before writing is a good way to minimize contention. Otherwise you'd have to synchronize during the writeObject(), which could tie up your Hashtable for a while.
ad 2. Is an ObjectOutputStream a good idea (so easy to write but is it fast and safe?), should I use buffering or something?
"Fast" is always relative, but I doubt you'll have any problem with the ObjectOutputStream here. What sort of "safety" do you mean? The only issue that comes to mind is that if the class definition changes for whatever class you're serializing, old serialized instances may not be readable by newer code. This isn't a probablem for Hashtable, since Sun makes sure that even when they change the implementation, the serialization is still compatible for older versions of the class (since JDK 1.0.2). However you might want to look at what classes you're using inside the Hashtable. If they're standard classes like String you're pretty safe; if they're classes that you write yourself, which you might edit later, you may need to learn more about things like serialVersionUID. I doubt this is much of a problem though, since you're generally just interested in reading a file that was written ~5 minutes ago; you probably haven't changed the class definition since then.
Using a BufferedOutputStream around your FileOutputStream is probably a good idea in general, as it often makes things a bit more efficient, and it's easy for you to do.
ad 3. I do the tempfile-and-move thing to make sure that when the application crashes (or when someone uses 'kill -9'), I will not end up with half an object. Good idea or unnecessary?
Sounds good to me. This is a good practice in general I think.


"I'm not back." - Bill Harding, Twister
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: backup hashtable