The language code uses Vector and Hashtable as well. I'm not very sure what
objects in the language layer are shared between across objects but I would
think that the bulk of stuff under impl/sql/compile could use unsync
collections?
On 12/4/06, Knut Anders Hatlen <[EMAIL PROTECTED]> wrote:
Hi,
I think I once read that the engine code in some cases uses
synchronized containers because the code was written before the
unsynchronized containers were added to the JDK, and not because
synchronization was needed. Is that correct?
I traced some simple operations and found that methods in synchronized
Hashtables and Vectors were called from these classes:
* SinglePool/LockSet (lock manager)
* Clock (cache manager)
* java.util.Observable
* org.apache.derby.impl.store.access.RAMTransaction
* org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext
The lock manager and the cache manager are accessed by multiple
concurrent threads, so they obviously need some kind of
synchronization. java.util.Observable is part of the JDK, so its
internal implementation is not under Derby's control. However, I'm not
sure that the synchronization is needed in RAMTransaction and
GenericLanguageConnectionContext.
In RAMTransaction, there is no explicit synchronization, but it
contains four Vectors and one Hashtable. Is it safe to assume that
RAMTransaction's methods are called from a single thread only and that
Vector/Hashtable could be replaced with ArrayList/HashMap?
In GenericLanguageConnectionContext, there are two for-loops which
iterate over the activations Vector and have this comment:
/* For every activation */
// synchronize on acts as other threads may be closing activations
// in this list, thus invalidating the Enumeration
However, I don't see how the code that follows this comment is safe if
another thread is modifying the Vector concurrently. For instance,
there is nothing that prevents another thread from removing an element
from the vector between the index calculation and the actual access to
the vector. This made me wonder whether the synchronization was needed
in the first place. Isn't it so that a thread will attempt to
synchronize on the connection object before it accesses the language
connection context? Or are there other ways to access the lcc?
I don't know these classes well enough to say whether it is safe to
replace the synchronized containers with unsynchronized ones, but I
hope someone more familiar with the code will comment.
Thanks,
--
Knut Anders
