db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Use of synchronized containers in engine code
Date Mon, 04 Dec 2006 15:30:27 GMT

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

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.


Knut Anders

View raw message