db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manish Khettry" <manish.khet...@gmail.com>
Subject Re: Use of synchronized containers in engine code
Date Mon, 04 Dec 2006 23:33:33 GMT
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

On 12/4/06, Knut Anders Hatlen <Knut.Hatlen@sun.com> 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

View raw message