Recently we found a very weird issue with active-objects and PostgresSQL about calling create() operation using active-objects. The issue is the transaction will always start with read-only mode, we already defined the method with @Transactional annotation and made sure that we didn’t set the read-only mode to true.
@Component
public class ConfigRepository extends AbstractConfigRepo implements ConfigRepository {
@Override
public ActivityConfig getSpaceConfig(String spaceKey) {
return getOrCreateConfig(spaceKey);
}
protected getOrCreateConfig(String key) {
return activeObjects.executeInTransaction(new TransactionCallback<E>() {
@Override
public E doInTransaction() {
return activeObjects.create(entityClass, params);
}
});
}
}
Whenever we calls the activeObjects.create() method, it will return an exception: cannot execute nextval() in a read-only transaction. This seems to be not possible as @Transactional default will be on read/write mode. And this issue only occurred in Confluence 7.16, we’ve been struggling for few days try to figure out what happened.
Thanks for your post. I’ve had a look at the code and nothing sticks out immediately. The only quibble might be for you to use @Repository as your annotation instead of @Component but ultimately that shouldn’t matter.
I do notice that from Confluence 7.16, PostgreSQL 10 is deprecated and marked with , and PostgreSQL 11 is the preferred version. What version are you running with?
I did a test on Confluence 7.16.2 and PostgreSQL 10 and I my transaction with activeObjects.create() worked fine.
I suspect there might be an issue with your configuration. If Confluence is running without issue, then it’s not at the database configuration layer otherwise Confluence would fail to start up.
Can I suggest you remove the @Transactional annotation. It’s not actually needed because you already have the create() wrapped in a transaction.
Thanks for this. I’m running Confluence 7.16.0 and PostgreSQL 11. The issue was triggered by one of the extractors after a page/space was created. I’m using com.atlassian.activeobjects:activeobjects-plugin 3.1.7.
I’m running out of ideas trying to figure out what configuration in my Confluence instance could impact this.
We tried to update the libraries to 4.0.0-m07 but the issue still exists. We have done some tests around this, when the activeObjects.create() was triggered by any other classes, it works fine. Only when the function is triggered by extractor module, we getting this read-only error.
The reason I mention it is because it’s been deprecated in Confluence 7.x, so please investigate using Extractor2 module and see if the issue still occurs.
Thanks for the advice, we’ve tried to replace all our Extractor module to Extractor2 Module, the read-only error is gone, but we got something else.
2022-03-17 18:06:49,142 WARN [Caesium-1-1] [confluence.impl.hibernate.ConfluenceHibernateTransactionManager] doRollback Performing rollback. Transactions:
->[com.atlassian.confluence.search.lucene.LuceneIncrementalIndexManager.flushQueue]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT,readOnly (Session #1313213592)
2022-03-17 18:06:49,155 WARN [Caesium-1-1] [confluence.impl.search.IndexFlushScheduler] lambda$new$1 Failed to flush index queue LuceneContentIndexFlusher, retry in 10s
org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:870)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:707)
at sun.reflect.GeneratedMethodAccessor203.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:344)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
at com.sun.proxy.$Proxy77.commit(Unknown Source)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:654)
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:407)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:215)
at com.sun.proxy.$Proxy189.flushQueue(Unknown Source)
at com.atlassian.confluence.impl.search.IndexFlushScheduler.lambda$new$1(IndexFlushScheduler.java:122)
at com.atlassian.confluence.impl.schedule.caesium.JobRunnerWrapper.doRunJob(JobRunnerWrapper.java:117)
at com.atlassian.confluence.impl.schedule.caesium.JobRunnerWrapper.lambda$runJob$0(JobRunnerWrapper.java:87)
at com.atlassian.confluence.impl.vcache.VCacheRequestContextManager.doInRequestContextInternal(VCacheRequestContextManager.java:84)
at com.atlassian.confluence.impl.vcache.VCacheRequestContextManager.doInRequestContext(VCacheRequestContextManager.java:68)
at com.atlassian.confluence.impl.schedule.caesium.JobRunnerWrapper.runJob(JobRunnerWrapper.java:87)
at com.atlassian.scheduler.core.JobLauncher.runJob(JobLauncher.java:134)
at com.atlassian.scheduler.core.JobLauncher.launchAndBuildResponse(JobLauncher.java:106)
at com.atlassian.scheduler.core.JobLauncher.launch(JobLauncher.java:90)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.launchJob(CaesiumSchedulerService.java:435)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeLocalJob(CaesiumSchedulerService.java:402)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeQueuedJob(CaesiumSchedulerService.java:380)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeJob(SchedulerQueueWorker.java:66)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeNextJob(SchedulerQueueWorker.java:60)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.run(SchedulerQueueWorker.java:35)
at java.lang.Thread.run(Thread.java:748)
2022-03-17 18:06:49,155 WARN [Caesium-1-1] [impl.schedule.caesium.JobRunnerWrapper] runJob Scheduled job LuceneContentIndexFlusher#LuceneContentIndexFlusher completed unsuccessfully with response JobRunnerResponse[runOutcome=FAILED,message='UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only']
It’s related to Lucene, we don’t have any usage on Lucene in our Extractor2 module. This error was also triggered from our Extractor2 implementation, do you think this could be the cause of this? If this is about Lucene, I can’t figure out why is this error pops up while we don’t have any usage on Lucene.
That stacktrace doesn’t look like it’s part of your code, does it? I might not be related at all. I will see if I can find reference to it in our bug list.
Yes, this stacktrace is not part of our code. And this error is actually preventing user from using our application on Confluence 7.16 onwards with PostgreSQL.
Either, it’s a bug we haven’t found yet or it’s something specific to your environment. What I would ask, is it possible to create the smallest P2 plugin that uses the Extractor2 module that still generates this error and try it in a clean Confluence server environment? That way we can determine if it’s a bug and narrow down the cause.
In the mean time, I’ll bring this up with the Confluence Server team.
, and PostgreSQL 11 is the preferred version. What version are you running with?