Jdbi: Docs / Exemple : Fournir un exemple (repo) pour montrer comment intégrer jdbi3 dans Spring-boot

Dans un cas simple, si vous n'avez pas besoin d'une intégration avec les fonctionnalités de transaction de Spring, vous pouvez simplement initialiser Jdbi et vos DAO dans une configuration 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);
    }

salut @bastman , @alwins0n contribue à une meilleure prise en charge de Spring dans # 989 - voudriez-vous revoir son travail jusqu'à présent et commenter si cela rend votre intégration Spring plus claire, ou si vous demandez quelque chose de légèrement différent ?

L'intégration de jdbi à Spring Boot est triviale, il vous suffit de configurer une méthode annotée @Bean dans votre classe @Configuration pour renvoyer une instance Jdbi - comme le montre @arteam

La chose la plus difficile, comme je l'ai fait dans mes relations publiques de printemps, est d'intégrer jdbi dans la gestion des transactions de printemps. Vous devriez certainement le vérifier, si c'est ce que vous recherchez.

De plus, si cela est approuvé, j'envisage de créer une configuration automatique/un démarreur à ressort pour le démarrage à ressort (2). si c'est ce que vous cherchez. (c'est en fait un bon exercice si vous voulez vous essayer : https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-developing-auto-configuration.html )

J'ai utilisé la méthode suivante avec jdbi2.x sans aucun problème. Je l'ai testé avec jdbi3.x et je n'ai vu aucun problème. Cela ressemble à un moyen plus simple de faire en sorte que Spring gère les transactions tout en utilisant jdbi.

Fondamentalement, vous enveloppez le proxy avec un TransactionAwareDataSourceProxy et l'utilisez pour créer l'instance Jdbi. (J'ai c/p'd de la réponse de @arteam pour que les exemples soient cohérents)

    <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);
    }

ça a l'air bien, je ne savais pas que cette classe existait.

pourriez-vous jeter un oeil dans le PR mentionné plus tôt? il y a déjà eu une suggestion concernant une fabrique de connexions "consciente des transactions" sous-jacente à jdbi.

iirc, le problème reste que la connexion et la poignée ne sont pas synchronisées en fonction de l'état. donc ce DS renvoie une connexion (qui est liée à la transaction) qui est fermée à la fin de la transaction. alors que le handle utilisé n'est pas fermé et lève des exceptions lors d'une tentative de (ré)utiliser.

mais peut-être que ce n'est pas un gros problème et plutôt un cas de coin et que votre solution convient à 99% des cas d'utilisation.

en bref : avec votre approche, la ressource gérée par la transaction est la connexion. dans mon PR, la ressource gérée est la poignée.

Il y a des problèmes liés à l'utilisation de jdbi3 avec stringtemplate4 et les importations de groupe. Voir mon problème https://github.com/jdbi/jdbi/issues/1052
Ce problème inclut également un lien vers un squelette de référentiel entièrement fonctionnel pour l'utilisation de jdbi3 dans Spring Boot 2.0.0

Lorsque j'implémente la solution de @kaandok avec l'annotation

« Gestion incorrecte des transactions détectée : un handle avec une transaction ouverte a été fermé. Les transactions doivent être explicitement validées ou annulées avant de fermer le handle. Jdbi a annulé cette transaction automatiquement. »

@cengha pouvez-vous fournir du code démontrant votre problème s'il vous plaît ?

Ci-dessous, la classe de configuration :

<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;
}

Voici la couche de service

    <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;
    }

Lorsque l'auto-commit est défini sur false, une erreur de transaction est mentionnée, mais s'il est défini sur true, il n'y a aucune erreur de transaction, mais cette fois, la restauration ne fonctionne pas (après l'exception d'exécution) et l'objet X est donc conservé dans la base de données. J'utilise Spring 2.0.3, JDBI 3.0.0-beta2 .

Problème résolu. J'utilisais une ancienne version de JDBI, après avoir remarqué que ce fil avait mis à jour la bibliothèque et que tout était résolu.