[
https://issues.apache.org/jira/browse/DERBY-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883502#action_12883502
]
Kristian Waagan commented on DERBY-4723:
----------------------------------------
Hi Wendy,
Thanks for reporting the issue.
The proposed fix sounds good, but before we implement it we may want to verify
that we indeed need this data to be shared.
As far as I can see, the id is used only for tracing. Having a local counter
together with the id for the real connection would uniquely identify a pooled
connection (would have to save this, since the real connection can be
nullified), but we would then loose creation ordering information.
In any case I think accessing the shared state in this case won't cause any
performance issues (once per pooled connection creation, minimal critical
section size).
Opinions anyone?
If I don't hear anything, I'll commit Wendy's proposed fix.
> Using an instance lock to protect static shared data in EmbedPooledConnection
> -----------------------------------------------------------------------------
>
> Key: DERBY-4723
> URL: https://issues.apache.org/jira/browse/DERBY-4723
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.5.1.1
> Reporter: Wendy Feng
> Priority: Minor
> Original Estimate: 0.17h
> Remaining Estimate: 0.17h
>
> EmbedPooledConnection has the unsafe synchronization as follow.
>
> private static int idCounter = 0;
> private synchronized int nextId()
> {
> return idCounter++;
> }
> idCounter is a static shared data, and it is not proper to use a instance
> lock to protect it, especially when two instance of the class are created.
> it would be more safer to write this instead:
> private static synchronized int nextId()
> {
> return idCounter++;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
