> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Thursday, May 31, 2012 5:23 PM > > > Yup: the solution is to just synchronize all the methods. If restart() is > synchronized, it will only operate while other methods are not actively > checking-out or checking-in connections. The big problem with the concept > of a "restart" is that there could be connections that are currently checked- > out during the call to recycle()... those need to be handled in some special > way -- probably added to a queue that will be processed later to destroy the > connections. >
That's what I will submit to commons-dbcp, then. > On the one hand, synchronizing these methods should not be necessary > because Java boolean values are defined to be 32-bit integers which feature > atomic assignment (that is, no thread ever sees only 8-bits of the 32-bit > value > being assigned and 24-bits of the old value). On the other hand, threads are > allowed to keep cached copies of certain data under certain conditions. Using > the keyword 'volatile' /should/, in recent JVMs, make the use of > 'synchronized' completely unnecessary, while older JVMs may even ignore > 'volatile' making 'synchronized' > mandatory. Use of 'synchronized' is the safest bet because it definitely > causes a 'memory barrier' to be crossed in any version of > JVM: that means that the thread is required to synchronize (perhaps a bad > choice of words) its cache with main memory which means that all variables > get the latest copies of the "real" data. Yep. That was my point too. What does it really matter anyway whether you are able to lock "this" in a getter. When you ask for the value, you are just asking for what is current. You have to protect yourself from non-initialized/null in any case. It just adds some unnecessary overhead ( to the JVM and brain ) to synchronize your getter when it doesn't mutate the data - unless I am missing something. --Brooke
