Jeff Kilbride

Greenhorn
+ Follow
since Apr 24, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jeff Kilbride

Thanks, Andrew. I'll give it a shot. I'm researching IP telephony -- which is why I need so many IPs per box.
--jeff
20 years ago
Anybody have a suggestion where I can post a question like this and have a better chance at a reply? Is there a bulletin board somewhere that specializes in kernel tweaks?
Thanks,
--jeff
20 years ago
I'm looking for a way to increase the number of aliased IP addresses I can have on my linux box, running RedHat 7.3 with a custom 2.4.20 kernel. Is there a parameter I can change in the kernel source to up the limit -- which I believe is somewhere around 450 as a default?
Any help is appreciated.
Thanks,
--jeff
20 years ago
Hi,
I've always had a nagging question about StringBuffers. Is the following initialization an okay thing to do? Or am I creating a bunch of unneccessary string objects -- where a and b are runtime variables, like request parameters?
String a = "the";
String b = "a";
StringBuffer s = new StringBuffer(a + " dog ate " + b + " bone.");
Or would I be better off doing:
StringBuffer s = new StringBuffer(25);
s.append(a);
s.append(" dog ate ");
s.append(b);
s.append(" bone.");
Or does it matter? I tend to use the first when building StringBuffers from variables, but am afraid I am creating a lot of extra strings...
Thanks,
--jeff
22 years ago
Thanks Peter. I appreciate the responses.
I was fairly skeptical about using a HashMap in this instance -- at least an unsynchronized one. Just wanted to get another point of view.
I think queuing and blocking would definitely be overkill in this scenario. I expect the cache to be up to date 99% of the time and the call to the DB to be very rare.
Thanks again!
--jeff
Ok, then for my example is it sufficient to use a Hashtable with no explicity synchronization in my code? Or do I need to synchronize the entire read/write block like:
<pre>
synchronized (Hashtable) {
StringArray = retrieve from Hash
if StringArray is null {
Build SQL statement
Retrieve from Database
if data exists {
build StringArray
Add to Hashtable
}
}
}
</pre>
This seems a little heavy handed, because I would say 99% of the time the Hash will be read as opposed to written to. If I synchronize the entire block, that will really impact performance.
Any alternatives?
Thanks,
--jeff
I have a caching structure in a servlet currently implemented with a Hashtable and I'm wondering if I can convert it to a HashMap for efficiency. The hash contains string arrays and corresponds to data in my database. I preload the hash in the servlet init() method and I have a background thread that updates the cache every six hours -- by creating a completely new hash and replacing the old. If new info is entered into the database between cache updates, I'd like to pick that up and reflect it in my cache. Here's some pseudo-code of what I'm doing:
<pre>
static Hashtable cache
// In doGet() method...
StringArray = retrieve array from Hashtable cache
if StringArray is null {
create sql statement and retrieve info from DB
if data exists in DB {
create new StringArray
add to Hashtable cache
}
}
</pre>
Pretty straightforward. I'm not trying to lock anything based on the keys or values in the hash, it's just storing info to avoid DB lookups. If two nearly simultaneous threads both make it to the DB call I don't really care. The second will just overwrite the first with the same key.
My question is: are individual key assignments and reads, to and from the Hashtable/HashMap, atomic? I'm assuming they are for Hashtables because of the internal synchronization, but what about HashMaps? Can two threads be simultaneously reading from and writing to the same key, so that the reading thread gets corrupted data? I'm afraid that a second thread may read from the cache while the first thread is in the middle of updating that particular key -- so that later in the code I may get some sort of exception due to a corrupted String Array value. When I say exception, I mean Java lang exception (like the Array thinks it has 20 elements, but only has 10 because it read the key halfway through the update process), not an exception generated by my code. Is this possible, or is the individual key unreadable until the update completes?
What exactly is synchronized in a Hashtable that is not synchronized in a HashMap?
Thanks,
--jeff
[This message has been edited by Jeff Kilbride (edited April 25, 2001).]
[This message has been edited by Jeff Kilbride (edited April 25, 2001).]
[This message has been edited by Jeff Kilbride (edited April 25, 2001).]