Registering two beans at the same time throws ConcurrentModificationException [SPR-12503]

[spring-projects-issues]

Lovro Mažgon opened SPR-12503 and commented

If two threads call the method DefaultListableBeanFactory#registerBeanDefinition at the same time, chances are that a ConcurrentModificationException will occur (for details see the StackOverflow answer). The problem is the List beanDefinitionNames, which is not thread-safe.

The bug was found in the version 3.2.2 but the same code persists until the latest version 4.1.2.

---

Affects: 3.2.2, 4.1.2

Reference URL: http://stackoverflow.com/questions/27280529/spring-registerbeandefinition-throws-java-util-concurrentmodificationexception/27280864#27280864

Issue Links:

• ConcurrentModificationException when executing AutowireCapableBeanFactory.createBean [SPR-13493] #18071 ConcurrentModificationException when executing AutowireCapableBeanFactory.createBean

Referenced from: commits 097bcfb

[spring-projects-issues]

Juergen Hoeller commented

Note that registerBeanDefinition isn't really meant to be called concurrently, at least not for registering new bean definitions on the fly... Replacing bean definitions at runtime is a different matter but still not really recommended.

That said, I'll have a look at what we can do here, in particular about the reset part. It's primarily about the tough tradeoffs between strong synchronization (as demanded here) and lock-free concurrent access to existing bean definition metadata.

In your specific use case, can you live with your containsBeanDefinition call and your registerBeanDefinition call not sharing a lock? In a race condition, you might replace an already existing bean definition when the if block is being entered twice...

Finally, I'm wondering why you're registering bean definition on the fly in the first place, in particular if they're prototypes. Could you possibly replace that arrangement with an AutowireCapableBeanFactory.createBean(Class) call, giving you a new unmanaged instance of such a bean (not requiring any registration), just with dependency injection applied but with no lifecycle management by the container?

Juergen

[spring-projects-issues]

Lovro Mažgon commented

I'm afraid I can't give you the answers, since someone else asked the question on SO. I only found out why the Exception is thrown and I wanted to let you know what can happen in such a use case.

[spring-projects-issues]

Pavol Miki commented

I also met the same exception. Here is the full stacktrace (maybe helpfull):

2015-02-20 12:25:52,001 [gui_scheduler3] ERROR [NO_USER] o.s.s.s.TaskUtils$LoggingErrorHandler handleError:95 - Unexpected error occurred in scheduled task.
java.util.ConcurrentModificationException: null
        at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) ~[na:1.8.0_20]
        at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734) ~[na:1.8.0_20]
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.doGetBeanNamesForType(DefaultListableBeanFactory.java:471) ~[spring-beans-4.1.4.RELEASE.jar:4.1.4.RELEASE]
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType(DefaultListableBeanFactory.java:412) ~[spring-beans-4.1.4.RELEASE.jar:4.1.4.RELEASE]
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType(DefaultListableBeanFactory.java:398) ~[spring-beans-4.1.4.RELEASE.jar:4.1.4.RELEASE]
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:337) ~[spring-beans-4.1.4.RELEASE.jar:4.1.4.RELEASE]
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:331) ~[spring-beans-4.1.4.RELEASE.jar:4.1.4.RELEASE]
        at org.springframework.transaction.interceptor.TransactionAspectSupport.determineTransactionManager(TransactionAspectSupport.java:370) ~[spring-tx-4.1.4.RELEASE.jar:4.1.4.RELEASE]
        at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:271) ~[spring-tx-4.1.4.RELEASE.jar:4.1.4.RELEASE]
        at org.springframework.transaction.aspectj.AbstractTransactionAspect.ajc$around$org_springframework_transaction_aspectj_AbstractTransactionAspect$1$2a73e96c(AbstractTransactionAspect.aj:70) ~[
spring-aspects-4.1.4.RELEASE.jar:4.1.4.RELEASE]
        at sk.....findByFilter) ...
        at sk.....getDataToBeFeeded() ...
        at sk.....feed() ...
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_20]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_20]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_20]
        at java.lang.reflect.Method.invoke(Method.java:483) ~[na:1.8.0_20]
        at org.springframework.scheduling.support.ScheduledMethodRunnable.run(ScheduledMethodRunnable.java:65) ~[spring-context-4.1.4.RELEASE.jar:4.1.4.RELEASE]
        at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54) ~[spring-context-4.1.4.RELEASE.jar:4.1.4.RELEASE]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_20]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_20]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_20]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_20]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_20]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_20]
        at java.lang.Thread.run(Thread.java:745) [na:1.8.0_20]

Rows started with "at sk....." is our application (Wicket (6.17.0), Spring (spring boot 1.2.1), Tomcat, java 8). The method findByFilter is annotated with @org.springframework.transaction.annotation.Transactional(readOnly = true, rollbackFor = Exception.class) and is invoked by spring scheduler.

[spring-projects-issues]

Juergen Hoeller commented

This should finally be covered through #18071 now. Feel free to give it an early try against the upcoming 4.2.2.BUILD-SNAPSHOT...

Juergen