db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Use of synchronized containers in engine code
Date Mon, 04 Dec 2006 18:17:33 GMT

Knut Anders Hatlen 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?
yes, of course one needs to check as it may be the case that sync is needed.
> 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 RAMTransaction sync is not needed, and they can be replaced with
the non-synced data containers.

> 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,

View raw message