Hello,
I'm not really sure why you are doing what you are doing but if you need key
value pairs that can be called arbitrarily you may consider a HashMap rather
then a HashTable. Perhaps you are creating a data or object pool..? If
everything is truly "read only" by the servlets it doesn't seem to me that
you would need the synchronization overhead except for that brief moment
when you update the data structure. In any case a HashMap is fail-fast so
if the data changes after an iterator object is created and before it
finishes it's task the iterator will safely fail -- you could easily write
into your code to throw and catch an error there and have the process loop
by using a flag during updates. I would imagine were talking about
milliseconds. Give your unique update thread a high priority --
(Thread.NORM_PRIORITY + 2)
Are the individual elements of various object types? If not perhaps a
simple array would be the quickest as you would eliminate the casting
overhead. If you order your array you can use a binary search or simply
create a position index to call elements directly from their position in the
array. It sounds like the size of your data object is constant. If you are
iterating through your data an array would certainly be faster. Usually
simpler is better.
I wonder how much overhead creating an iterator costs? Perhaps create an
iterator pool.
Just a few thoughts. Sounds like you aren't having any troubles.
Best Regards,
Craig
Oh yea....how's your tomcat? Mine are doing great.
-----Original Message-----
From: Jeff Kilbride [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 3:54 PM
To: [EMAIL PROTECTED]
Subject: Re: ArrayList vs. Vector
Ok, that makes sense, but I don't think it applies to my case. Most of the
caching I'm doing is read-only for the servlet. I pull the info out of my
database during the init and spawn a thread to refresh the Hashtable every
six hours. By refresh, I mean I'm creating a new Hashtable object and
replacing the current cache with the new object. I'm assuming that replacing
the entire object won't wreak havoc on any current accesses -- that the
replace will wait until any current synchronized accesses have finished.
That may be a bad assumption.
In the one instance in my code where I'm doing something similar to what you
have, I'm still pulling info from my database to create the object to be
cached. If two requests come in nearly simultaneously, they'll both pull the
same info from my database and the second will overwrite the first in my
cache. No big deal, because they both contain the same info/same key. I'm
not sure if synchronizing the whole block is worthwhile in this case. Any
strong argument why I should?
Thanks,
--jeff
----- Original Message -----
From: "William Kaufman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 23, 2001 2:39 PM
Subject: RE: ArrayList vs. Vector
> > I still use Vectors/Hashtables when I need thread safety, though. Does
> > anyone know if it's faster/better to wrap one of the new
> > collection classes in a Collections.synchronized* class instead?
>
> I'd expect Vector/Hashtable to be a little faster: they subclass
> ArrayList/HashMap, where synchronized Collections are proxies.
>
> But, really, neither one works.
>
> Any places you'd use a collection, it's usually insufficient to
synchronize
> the specific access: what you need to do is synchronize a block of
accesses.
> For instance, here's a simple cache of "Foo" objects (each identified by
> name), implemented with a Hashtable:
>
> Hashtable fooCache = new Hashtable();
>
> public Foo getFoo(String name)
> {
> Foo foo = (Foo)fooCache.get(name);
> if (foo == null)
> {
> foo = new Foo(name);
> fooCache.put(name, foo);
> }
> return foo;
> }
>
> If you only want one Foo allocated per name--always--this caching
mechanism
> will break down. You'd need to synchronize around _all_ accesses to the
> fooCache, whether it's a Hashtable or a HashMap. In other words,
> synchronizing the table's access methods don't buy you anything--you need
to
> synchronize _across_ calls. And once you synchronize it correctly,
> synchronizing specific methods just slows you down.
>
> So, you should implement the above code as,
>
> HashMap fooCache = new HashMap();
>
> public Foo getFoo(String name)
> {
> synchronized (fooCache)
> {
> Foo foo = (Foo)fooCache.get(name);
> if (foo == null)
> {
> foo = new Foo(name);
> fooCache.put(name, foo);
> }
> return foo;
> }
> }
>
> This may be a peculiar case for you, but you're probably doing something
> which needs similar synchronization--whatever kind of collection you're
> using.
>
> -- Bill K.
>
>
> > -----Original Message-----
> > From: Jeff Kilbride [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, April 23, 2001 2:06 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: ArrayList vs. Vector
> >
> >
> > I recently re-wrote some older java code (jdk 1.1 based) and
> > one of my goals
> > was to use the new collection classes. I moved all of my
> > Hashtables/Vectors
> > that didn't need to be thread safe to HashMaps/ArrayLists. No
> > problems under
> > Tomcat.
> >
> > I still use Vectors/Hashtables when I need thread safety, though. Does
> > anyone know if it's faster/better to wrap one of the new
> > collection classes
> > in a Collections.synchronized* class instead? It just seems
> > easier to me to
> > use Vectors/Hashtables, since they're already internally synchronized.
> >
> > Thanks,
> > --jeff
> >
> > ----- Original Message -----
> > From: "Hunter Hillegas" <[EMAIL PROTECTED]>
> > To: "Tomcat User List" <[EMAIL PROTECTED]>
> > Sent: Monday, April 23, 2001 12:36 PM
> > Subject: ArrayList vs. Vector
> >
> >
> > > I use Vectors in some parts of my Web app and I'm thinking
> > about using
> > > ArrayLists instead...
> > >
> > > Any caveats to using them in a Web app environment?
> > >
> > > Hunter
> > >
> >
>
