https://issues.apache.org/bugzilla/show_bug.cgi?id=46209
--- Comment #4 from Sebb <[EMAIL PROTECTED]> 2008-11-14 04:04:13 PST --- There are quite a few cases of class variables that are not final, even though they are set in the constructor and not actually changed thereafter. For example, ConnectionPool:pool FairBlockingQueue:lock, items, waiters Wherever possible, variables should be made final to ensure thread-safety. There are some variables that are protected, even though there is already an access method for them. For example, DataSourceProxy:driver In this case, the variable should definitely be private, as access needs to be synchronized. PooledConnection:counter is volatile, presumably instead of synchronising it. However, volatile does not protect against the read-modify-write involved in processing the counter++ statement. Same applies to PoolProperties:poolCounter Also, both of these are protected. I think they should be final. It would be useful to use Javadoc to state the class thread-safety or otherwise, and to add details of how fields are synchronised, e.g. using the @GuardedBy annotation. It's confusing to have aliases such as: final ReentrantLock lock = FairBlockingQueue.this.lock; when the code works just the same without. Some source files still have the following copyright: Copyright: Copyright (c) 2008 Filip Hanik -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
