getMapper, getUDTCodec and getAccessor as singletons

[Havhev Car My]

Well, this is a minor one.

While working on JAVA-1310 I've noticed this condition from the JavaDoc is not always met:

The {@code MappingManager} only ever keeps one Mapper for each class, and so calling this method multiple times on the same class will always return the same object.

Well, when trying to retrieve a mapper (or a codec or an accessor)  the code is synchronized on the class 'mappers' field which is non-final and changing. So this scenario is totally realistic:

1) Thread A runs 'getMapper(Foo.class)', enters and and passes this line.

2) At that moment thread B does 'getMapper(Goo.class)' -> and get blocked at the same line

3) At this point thread A finished and changes mappers at this line 

4) At this point thread C enters 'getMapper(Goo.class)' and passes  this line since thread B and thread C are locked on a different object,

At this point threads B and C both inside the blocking code and either of them is going to generate a different instance for Mapper<Goo> , one of them will be stored, but both receive a different instance.

Again, this is a minor one and can easily be solved. You can open a ticked and i'll supply a pull request of a few line changes to fix it. 

[Alexandre Dutra]

Hi Hahvev,

Yes, we have an ugly (and broken) double-checked locking algorithm in the mapper that has been around for ages (at least, as far as I can remember). All of this should be replaced with a call to ConcurrentMap.putIfAbsent() or something equivalent.

Your contribution would be highly appreciated (as was the one for JAVA-1310).

Thank you for your interest in our driver!

Alexandre

--
You received this message because you are subscribed to the Google Groups "DataStax Java Driver for Apache Cassandra User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-driver-us...@lists.datastax.com.

--

Alexandre Dutra

Driver & Tools Engineer @ DataStax