java – 声明性事务和TransactionAwareDataSourceProxy与JOOQ结合的问题

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了java – 声明性事务和TransactionAwareDataSourceProxy与JOOQ结合的问题，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含6035字，纯文字阅读大概需要9分钟。

内容图文

我有一个数据源配置类,如下所示,使用单独的DataSource bean,用于使用JOOQ的测试和非测试环境.在我的代码中,我不使用DSLContext.transaction(ctx – > {…},而是将该方法标记为事务性,以便JOOQ遵循Spring的事务性声明式事务.我使用的是Spring 4.3.7.RELEASE.

我有以下问题：

>在测试期间(JUnit),@ Transaction按预期工作.无论我使用DSLContext的store()方法多少次,单个方法都是事务性的,而RuntimeException会触发整个事务的回滚.
>在实际生产运行期间,完全忽略@Transactional.方法不再是事务性的,TransactionSynchronizationManager.getResourceMap()包含两个单独的值：一个显示到我的连接池(不是事务性的),另一个显示TransactionAwareDataSourceProxy.

在这种情况下,我原本只期望一个TransactionAwareDataSourceProxy类型的资源包装我的DB CP.

>使用我做的第二组配置更改(在下面用“AFTER”注释)进行了大量的试验和错误后,即使在运行时,@ Transaction也能正常工作,尽管TransactionSynchronizationManager.getResourceMap()包含以下值：

在这种情况下,我的DataSourceTransactionManager似乎甚至不知道TransactionAwareDataSourceProxy(很可能是因为我传递了简单的DataSource,而不是代理对象),这似乎完全“跳过”了代理.

我的问题是：我的初始配置似乎是正确的,但没有用.建议的“修复”有效,但IMO根本不起作用(因为事务管理器似乎并不知道TransactionAwareDataSourceProxy).

这里发生了什么？有没有更清洁的方法来解决这个问题？

BEFORE(在运行时不是事务性的)

@Configuration
@EnableTransactionManagement
@RefreshScope
@Slf4j
public class DataSourceConfig {

    @Bean
    @Primary
    public DSLContext dslContext(org.jooq.Configuration configuration) throws SQLException {
        return new DefaultDSLContext(configuration);
    }

    @Bean
    @Primary
    public org.jooq.Configuration defaultConfiguration(DataSourceConnectionProvider dataSourceConnectionProvider) {
        org.jooq.Configuration configuration = new DefaultConfiguration()
            .derive(dataSourceConnectionProvider)
            .derive(SQLDialect.POSTGRES_9_5);
        configuration.set(new DeleteOrUpdateWithoutWhereListener());
        return configuration;
    }

    @Bean
    public DataSourceTransactionManager transactionManager(DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }

    @Bean
    public DataSourceConnectionProvider dataSourceConnectionProvider(DataSource dataSource) {
        return new DataSourceConnectionProvider(dataSource);
    }

    @Configuration
    @ConditionalOnClass(EmbeddedPostgres.class)
    static class EmbeddedDataSourceConfig {

        @Value("${spring.jdbc.port}")
        private int dbPort;

        @Bean(destroyMethod = "close")
        public EmbeddedPostgres embeddedPostgres() throws Exception {
            EmbeddedPostgres embeddedPostgres = EmbeddedPostgresHelper.startDatabase(dbPort);
            return embeddedPostgres;
        }

        @Bean
        @Primary
        public DataSource dataSource(EmbeddedPostgres embeddedPostgres) throws Exception {
            DataSource dataSource = embeddedPostgres.getPostgresDatabase();
            return new TransactionAwareDataSourceProxy(dataSource);
        }
    }

    @Configuration
    @ConditionalOnMissingClass("com.opentable.db.postgres.embedded.EmbeddedPostgres")
    @RefreshScope
    static class DefaultDataSourceConfig {

        @Value("${spring.jdbc.url}")
        private String url;

        @Value("${spring.jdbc.username}")
        private String username;

        @Value("${spring.jdbc.password}")
        private String password;

        @Value("${spring.jdbc.driverClass}")
        private String driverClass;

        @Value("${spring.jdbc.MaximumPoolSize}")
        private Integer maxPoolSize;

        @Bean
        @Primary
        @RefreshScope
        public DataSource dataSource() {
            log.debug("Connecting to datasource: {}", url);
            HikariConfig hikariConfig = buildPool();
            DataSource dataSource = new HikariDataSource(hikariConfig);
            return new TransactionAwareDataSourceProxy(dataSource);
        }

        private HikariConfig buildPool() {
            HikariConfig config = new HikariConfig();
            config.setJdbcUrl(url);
            config.setUsername(username);
            config.setPassword(password);
            config.setDriverClassName(driverClass);
            config.setConnectionTestQuery("SELECT 1");
            config.setMaximumPoolSize(maxPoolSize);

            return config;
        }
    }

AFTER(运行时期间的事务,正如预期的那样,所有未列出的bean与上面相同)

@Configuration
@EnableTransactionManagement
@RefreshScope
@Slf4j
public class DataSourceConfig {

    @Bean
    public DataSourceConnectionProvider dataSourceConnectionProvider(TransactionAwareDataSourceProxy dataSourceProxy) {
        return new DataSourceConnectionProvider(dataSourceProxy);
    }

    @Bean
    public TransactionAwareDataSourceProxy transactionAwareDataSourceProxy(DataSource dataSource) {
        return new TransactionAwareDataSourceProxy(dataSource);
    }

    @Configuration
    @ConditionalOnMissingClass("com.opentable.db.postgres.embedded.EmbeddedPostgres")
    @RefreshScope
    static class DefaultDataSourceConfig {

        @Value("${spring.jdbc.url}")
        private String url;

        @Value("${spring.jdbc.username}")
        private String username;

        @Value("${spring.jdbc.password}")
        private String password;

        @Value("${spring.jdbc.driverClass}")
        private String driverClass;

        @Value("${spring.jdbc.MaximumPoolSize}")
        private Integer maxPoolSize;

        @Bean
        @Primary
        @RefreshScope
        public DataSource dataSource() {
            log.debug("Connecting to datasource: {}", url);
            HikariConfig hikariConfig = buildPoolConfig();
            DataSource dataSource = new HikariDataSource(hikariConfig);
            return dataSource; // not returning the proxy here
        }
    }
}

解决方法:

我会把我的评论变成一个答案.

事务管理器不应该知道代理.从documentation：

Note that the transaction manager, for example
DataSourceTransactionManager, still needs to work with the underlying
DataSource, not with this proxy.

TransactionAwareDataSourceProxy类是一个特殊目的类,在大多数情况下是不需要的.通过Spring框架基础结构与数据源连接的任何东西都不应该在其访问链中具有代理.代理适用于无法与Spring基础结构连接的代码.例如,已经设置为使用JDBC并且不接受任何Spring的JDBC模板的第三方库.这与上述相同的文档中说明：

This proxy allows data access code to work with the plain JDBC API and
still participate in Spring-managed transactions, similar to JDBC code
in a J2EE/JTA environment. However, if possible, use Spring’s
DataSourceUtils, JdbcTemplate or JDBC operation objects to get
transaction participation even without a proxy for the target
DataSource, avoiding the need to define such a proxy in the first
place.

如果您没有任何代码需要绕过Spring框架,那么根本不要使用TransactionAwareDataSourceProxy.如果您确实有这样的遗留代码,那么您将需要执行第二次设置中已配置的代码.您将需要创建两个bean,一个是数据源,另一个是代理.然后,您应该将数据源提供给所有Spring托管类型以及遗留类型的代理.

内容总结

以上是互联网集市为您收集整理的java – 声明性事务和TransactionAwareDataSourceProxy与JOOQ结合的问题全部内容，希望文章能够帮你解决java – 声明性事务和TransactionAwareDataSourceProxy与JOOQ结合的问题所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端