Both Hashtable and Vector are legacy, synchronized collections. This means that basic operations (adding/putting a value) and reading the collection will not interfere...
... unless you use iterators.
The 'problem' is that synchronized collections (such as Vector, Hashtable and those returned by Collections.synchronizedXyz methods) provide fail-fast iterators. Each collection maintains a modification count; when the iterator is created, it saves the value of the counter, and whenever you call next() on the iterator, it compares the saved value with the current one, and throws ConcurrentModificationException if they differ. The reason is that it's not safe to continue and use the iterator - maybe an element has been added to the collection, which would probably not affect your iteration, but maybe some/all elements were removed, or elements have been inserted at the head of the list.
add(), put() and remove() are all atomic operations. Iterating is not. To iterate safely, you should, before creating the iterator, grab the same lock that the collection's methods use, and not release it until you are done. Note that Vector's Javadoc does not mention whether its methods synchronize on the Vector object itself (which would allow you to synchronize on the Vector), or some internal object (which would make safe iteration impossible).
Be sure to check out for hidden iterators, such as those used by the 'foreach' loop.
To use fail-safe iterators, use CopyOnWriteArrayList or ConcurrentHashMap (or other collection classes in java.util.concurrent).
Aside from iterators, any operation that involves several accesses to the collection (even if it's position based, not iterator-based) would run the same risks. Imagine summing the elements in a list: if you don't do this in a synchronized block (or use CopyOnWriteArrayList), you'll run into consistency issues at all levels (the data, as well as the length of the list may change while you're working on it).
Java Concurrency in Practice is a great book on the topic.