#288 DozerBeanMapper initialization is not thread safe

Dozer v5.3.1
closed-fixed
nobody
None
8
2010-11-07
2010-11-03
Anonymous
No

When multiple threads access the DozerBeanMapper (as a singleton), a situation can arise where threads try to get a mapping processor before the class mapping initialization has been completed. What happens is that the first thread calls getMappingProcessor, and loading of mapping files is started, but before this process is completed, other threads calls getMappingProcessor, and instead of waiting until the loading of mapping files has been completed, execution is continued with uninitialized class mappings.

Discussion

  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2010-11-03

    Test to expose the bug

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2010-11-03
    • priority: 5 --> 7
     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2010-11-03
    • priority: 7 --> 8
     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2010-11-03

    It appears that the problem also applies to the method getClassMap in MappingProcessor. Multiple threads can see that the mapping is 'null' and attempt to create and add a new mapping to the classMappings table, which results in a "Duplicate Class Mapping Found".

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2010-11-03

    The previous comment is somewhat wrong. A new MappingProcessor instance is created for each thread, but each instance operates on a common instance of classMappings, which causes the problem.

     
  • dmitry (lv)

    dmitry (lv) - 2010-11-07
    • milestone: 1163967 --> Dozer v5.3.1
    • status: open --> closed-fixed
     
  • dmitry (lv)

    dmitry (lv) - 2010-11-07

    fixed in trunk. Will be releasing 5.3.1 this week.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks