[
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
