Jdbi: Docs / Exemplo: Forneça um exemplo (repo) para mostrar como integrar jdbi3 no spring-boot

Em um caso simples, se você não precisa de uma integração com os recursos de transação do Spring, você pode apenas inicializar Jdbi e seus DAOs em uma configuração Spring:

    <strong i="7">@Bean</strong>
    public DataSource dataSource() {
        // From Spring Boot's connection pool configuration;
    }

    <strong i="8">@Bean</strong>
    public Jdbi createJdbi(DataSource dataSource) {
        return Jdbi.create(dataSource);
    }

    <strong i="9">@Bean</strong>
    public UserDao userDao(Jdbi jdbi) {
        return jdbi.onDemand(UserDao.class);
    }

oi @bastman , @ alwins0n está contribuindo com um melhor suporte ao Spring em # 989 - você gostaria de revisar o trabalho dele até agora e comentar se ele torna sua integração do Spring mais clara ou se você está pedindo algo um pouco diferente?

Integrar jdbi ao Spring Boot é trivial, você só precisa configurar um método @Bean anotado em sua classe @Configuration para retornar uma instância Jdbi - como mostrado por @arteam

A coisa mais difícil, como feito em meu PR da primavera, é integrar o jdbi ao gerenciamento de transações da primavera. Você deve definitivamente dar uma olhada, se é o que você está procurando.

Além disso, se isso for aprovado, estou pensando em criar uma inicialização automática / boot com mola para boot com mola (2). se é isso que você está procurando. (na verdade, é um bom extrato se você quiser tentar por si mesmo: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-developing-auto-configuration.html)

Tenho usado o seguinte método com jdbi2.x sem problemas. Estive testando com jdbi3.x e não encontrei nenhum problema. Essa parece uma maneira mais simples de fazer com que o spring gerencie transações enquanto usa jdbi.

Basicamente, você envolve o proxy com um TransactionAwareDataSourceProxy e usa isso para criar a instância Jdbi. (Eu c / p'd da resposta de @arteam para que os exemplos sejam consistentes)

    <strong i="8">@Bean</strong>
    public DataSource dataSource() {
        // From Spring Boot's connection pool configuration;
    }

    <strong i="9">@Bean</strong>
    public TransactionAwareDataSourceProxy txDataSource(DataSource dataSource) {
        return new TransactionAwareDataSourceProxy(dataSource);
    }

    <strong i="10">@Bean</strong>
    public PlatformTransactionManager transactionManager(DataSource dataSource) {
        //not sure if this is needed
        return new DataSourceTransactionManager(dataSource);
    }

    <strong i="11">@Bean</strong>
    public Jdbi createJdbi(TransactionAwareDataSourceProxy dataSource) {
        //note that parameter is TransactionAwareDataSourceProxy instead of plain DataSource
        return Jdbi.create(dataSource);
    }

    <strong i="12">@Bean</strong>
    public UserDao userDao(Jdbi jdbi) {
        return jdbi.onDemand(UserDao.class);
    }

parece bom, eu não sabia que essa classe existia.

você poderia dar uma olhada no PR mencionado anteriormente? já houve uma sugestão sobre um connection factory "ciente de transação" subjacente ao jdbi.

iirc, o problema continua sendo que a conexão e o identificador não estão sincronizados. portanto, este ds retorna uma conexão (que está ligada à transação) que é fechada no final da transação. enquanto o identificador usado não é fechado e lança exceções na tentativa de (re) usá-lo.

mas talvez isso não seja um grande negócio e sim um caso esquivo e sua solução se encaixa em 99% dos casos de uso.

em resumo: com sua abordagem, o recurso gerenciado por transação é a conexão. no meu PR, o recurso gerenciado é a alça.

Há problemas relacionados ao uso de jdbi3 com stringtemplate4 e importações de grupo. Veja meu problema https://github.com/jdbi/jdbi/issues/1052
Este problema também inclui um link para um esqueleto de repo totalmente funcional para usar jdbi3 no spring boot 2.0.0

Quando eu implementar @kaandok solução 's com anotação @Transactional da Primavera, eu recebo seguinte exceção devido ao fechamento pegas quando existe transações abertas. Existe alguma solução recomendada / aplicável para isso?

"Manipulação de transação imprópria detectada: Um Handle com uma transação aberta foi fechado. As transações devem ser explicitamente confirmadas ou revertidas antes de fechar o Handle. Jdbi reverteu esta transação automaticamente."

@cengha você pode fornecer algum código demonstrando seu problema, por favor?

Abaixo está a classe de configuração:

<strong i="6">@Bean</strong>
public HikariDataSource hikariDataSource() {
    HikariConfig dataSourceConfig = new HikariConfig();
    dataSourceConfig.setDriverClassName(driverClassName);
    dataSourceConfig.setJdbcUrl(jdbcUrl);
    dataSourceConfig.setUsername(username);
    dataSourceConfig.setPassword(password);
    dataSourceConfig.setAutoCommit(true);
    return new HikariDataSource(dataSourceConfig);
}

<strong i="7">@Bean</strong>
public TransactionAwareDataSourceProxy transactionAwareDataSourceProxy(HikariDataSource dataSource) {
    return new TransactionAwareDataSourceProxy(dataSource);
}

<strong i="8">@Bean</strong>
public PlatformTransactionManager platformTransactionManager(HikariDataSource dataSource) {
    return new DataSourceTransactionManager(dataSource);
}

<strong i="9">@Bean</strong>
public Jdbi jdbi(TransactionAwareDataSourceProxy transactionAwareDataSourceProxy) {
    Jdbi jdbi = Jdbi.create(transactionAwareDataSourceProxy);
    jdbi.installPlugin(new SqlObjectPlugin());
    return jdbi;
}

Aqui está a camada de serviço

    <strong i="13">@Override</strong>
    <strong i="14">@Transactional</strong>
    public Long createX(X x) {
        Long aLong = XDao.insertX(x);
        if(true) throw new RuntimeException();
        return aLong;
    }

Quando o auto-commit é definido como false, eu mencionei o erro de transação, mas se for definido como true, não há nenhum erro de transação, mas desta vez a reversão não funciona (após a exceção de tempo de execução) e, portanto, o objeto X está sendo persistido no banco de dados. Eu uso o spring 2.0.3, JDBI 3.0.0-beta2.

Problema resolvido. Eu estava usando uma versão mais antiga do JDBI, após perceber que esse tópico atualizou a biblioteca e tudo resolvido.