db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4723) Using an instance lock to protect static shared data in EmbedPooledConnection
Date Tue, 29 Jun 2010 10:15:49 GMT

    [ 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.


Mime
View raw message