db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4724) Unsafe synchronization in GenericStatement
Date Wed, 16 Feb 2011 23:59:32 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995590#comment-12995590
] 

Dag H. Wanvik commented on DERBY-4724:
--------------------------------------

I am not sure if this is a bug: it seems to me that in the case where both threads have allocated
a new preparedStatement, the synchronization is really not needed, but it's there for the
other case: when caching is enabled and both threads proceed with the same prepared statement.

> Unsafe synchronization in GenericStatement
> ------------------------------------------
>
>                 Key: DERBY-4724
>                 URL: https://issues.apache.org/jira/browse/DERBY-4724
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.5.1.1
>            Reporter: Wendy Feng
>            Priority: Minor
>
> GenericStatement has some statements in method prepMinion()  like this:
>        if (preparedStmt == null) 
> 		{
> 			if (cacheMe)
> 				preparedStmt = (GenericPreparedStatement)((GenericLanguageConnectionContext)lcc).lookupStatement(this);
> 			if (preparedStmt == null) 
> 			{
> 				preparedStmt = new GenericPreparedStatement(this);
> 			}
> 			else
> 			{
> 				foundInCache = true;
> 			}
> 		}
> 		synchronized (preparedStmt) 
> 		{
>                      ...
>                }
> It is not safe to assgine a new object to preparedStmt before synchronizing on. 
> it may results sycnchronize on two different object if the method is called concurrently
when preparedStmt =null.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message