A very good description is provided on the forum
http://sourceforge.net/projects/dozer/forums/forum/452530/topic/4672635
Essentially when using MapperAware Interface the should be a way to specify something to the affect of getInstance() on the CustomConverter thus allowing a new instance of the CustomConverter to be created for the current thread/execution. However a better long term solution would be to have CustomConverterFactory but that would require some redesign of how CustomConverters currently work as this is only a thread safety issue when using MapperAware it would be a simple fix that at the same time still allows users to decide how they want to implement the getInstance() method of the MapperAware interface.
Well, I found myself with the same problem. I have downloaded the code and start to dig on it. It seems that both MapperAware and ConfigurableCustomConverter introduce this undessire behaviour.
What I did (I am submitting a patch) was:
* Remove those both interfaces
* Added Mapper and Parameters as part of the public convert method of CustomConverter.
* Modified MappingProcessor.mapUsingCustomConverterInstance to pass through this new variables as method parameters.
This will obviously push to some code changes on client customerConverters, but will avoid the concurrency problem.
Well, I have created a new issue and submitted the patch there. See ID: 3445344