tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hedrick, Brooke - 43" <>
Subject RE: Question about resetting datasources and changes to the BasicDataSource.close() method
Date Fri, 01 Jun 2012 15:54:23 GMT
> -----Original Message-----
> From: Christopher Schultz []
> 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.


View raw message