Fixing thread safety issue relating to cached setter lookups

[mattlevine]

We ran into an issue where transient beans where being returned with their setters not set. It only happened when there were concurrent threads accessing instances of the same bean class.

Thanks for the project!
Matt

[seancorfield]

Thanx. I took a look and I'm not clear how your patch solves the general thread safety here. Could you explain?

I'm concerned that this might just hide the issue and it will crop up elsewhere.

[mattlevine]

In the previous version

var setterMeta = variables.settersInfo[ beanName ];
setterMeta.bean = bean;

The transient bean is set into the persistent struct variables.settersInfo[ beanName ] . This resulted in parallel request for the same beanName stepping on each other. Basically request B would get request A's dependency injection.

As far as I can tell it's isolated to this specific case. The change I'm proposing is actually very similar to how you return values from the cachable() function. It just removes any pass by reference issues.

[seancorfield]

OK. Let me take another look at what's in that struct and see if I can solve the race condition at source instead, but I may just accept this PR anyway...

[seancorfield]

I looked at whether to eliminate the settersInfo cache based on findSetters() always returning a new struct instance (which only ever contains a single member, setters) but I can see now why it's worth caching and I see that it isn't a race condition but just a mixing of singleton and transient data. Your patch looks good (apart from formatting :)

[seancorfield]

Thanx.