db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Use of synchronized containers in engine code
Date Mon, 04 Dec 2006 15:45:58 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. As you point out replacing them with unsynchronized Java 2 
collections does require investigation as to the possible code paths 
into the object.

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

I think you are correct on this.

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

That comment *may* be from the time activations were closed in 
finalization (which lead to deadlocks). Since activations are now just 
marked as inactive by finalization it most likely true that the Vector 
could be replaced by an ArrayList.


View raw message