Thanks, Stephen. Great way to preserve compatibility while effectively dealing with the problem. If there are no objections, I will make this change.
Phil On 8/7/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
You might want to look at [collections] ExtendedProperties where I just fixed a similar issue. I made the instance methods work against a new instance variable, and subclasses could still alter the static one, which now acts as a default. Stephen Phil Steitz wrote: > As stated in the bug report: > > "SharedPoolDataSource.getPooledConnectionAndInfo() is synchronized > _instance_ > method, but it accesses SharedPoolDataSource.userKeys which is a _static_ > variable, so if you have more than one instance of SharedPoolDataSource > (as we > do) access to the map would not be properly synchronized. So either map > should > be made instance variable, or the method should be synchronized on the > class, > not instance." > > I would very much appreciate comments on the options to fix this, > including "WONTFIX", but I don't like that option. I have coded the > change to synchronize the method on the class (or more precisely, to > make its body synchronized on the class, since it can't be static), > but am hesitant to make that change. Any better ideas? Any > recollections / rationale for why the map is static? > > Thanks! > > Phil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
