Jdbi: @CreateSqlObjectの混乱を少なくします。

これを報告していただきありがとうございます。 ここで技術的に重大な変更が行われることになると思いますが、既存の動作は十分に貧弱であるため、3.xリリースサイクルの早い段階で技術的に重大な変更を加えることができます。 既存の動作に依存している場合、またはここで小さな重大な変更を出荷する可能性に同意しない場合は、この問題にフラグを立ててください。

_why_ @CreateSqlObjectに関するコンテキストのためだけに、オンデマンドではうまく機能しません。

• オンデマンドはコアレベルの抽象化であり、プロキシを使用して実装されます。 オンデマンドプロキシでメソッドを呼び出すと、実際のSQLオブジェクトが作成され、メソッド呼び出しが実際のSQLオブジェクトに委任されます。 その実インスタンスをサポートするハンドルは、デリゲートメソッド呼び出しが戻った後に閉じられます。
• @CreateSqlObjectは、元のSQLオブジェクトのバッキングハンドルを使用してhandle.attach(sqlObjectType)を使用して実装されます。

したがって、作成されたSQLオブジェクトのバッキングハンドルは、SQLオブジェクトが返される前に閉じられます。

上記のどれも決まっていない-それはまさに今それが実装されている方法です。

これを修正するために互換性を破る必要があるとは思いません。

申し訳ありませんが、実際にはわかりません... onDemandとCreateSqlObjectの正確な問題は何ですか？ 私はそれで問題を抱えたことは一度もありません、そして@qualidafialの説明についての何かが私の心を傾けさせているだけです...

fooProxy.usecaseの呼び出しのために接続が取得されます。 Foo.usecaseは、createSqlObjectメソッドバーを呼び出します。このバーは、現在の（ユースケースの）ハンドルにアタッチした後に新しいバーを返します。 ユースケースが戻ると、ユースケースのハンドルは閉じられます。 返されたBarと非同期で何もしていない限り、 barのハンドルが早く期限切れになるのはどうしてですか？ バーのライフサイクルと使用は、ハンドルと同様にFoo.usecaseの本体に限定されています。

JDBIの内部について話すことはできませんが、本番環境で見た動作についてコメントすることはできます。

基本的に、私たちのより低い環境では物事は大丈夫でした。 しかし、本番環境での負荷が増えると、SQLステートメントが適切なデータベースノードに対して実行されないことが継続的に発生します。 たとえば、読み取り専用の選択はマスターノードにヒットし、挿入は読み取りレプリカにヒットします。 さらに、操作の途中で接続が閉じられるというエラーが発生しました。

基本的に、 @ CreateSqlObjectによってスレッドセーフの問題が発生したようです。つまり、競合するリクエストによって読み取り専用フラグが変更されていました。

問題を「解決」するために、 @CreateSqlObjectの使用をすべて削除し、次のようになりました。

• class FooDao
• class BarDao
• class CombinedDao extends FooDao, BarDao

そして、 jdbi.onDemand(CombinedDao)し、それを介したアクセスのみを使用します。
そのパターンに切り替えることで、それほどきれいではありませんが、本番環境での前述のエラーをすべて取り除くことができました。

ちなみに、現時点ではすべてのコードが抽象クラスでonDemandを使用しているため、JDBI 2に戻ることを考えています。また、満足のいく方法で再構築する方法を理解できません。

私は、ロジックを含むがSQLを含まない抽象実装クラスを持ち、トランザクションとして注釈が付けられたメソッドを持ち、CreateSqlObjectを使用して純粋にSQLであるDAOクラスへのアクセスを提供するサービスインターフェイスを持つ傾向があります。 簡単な例：

インターフェース

public interface AccountService {
    void addAccount(Account account, User user);
}  

実装

public abstract class AccountServiceJdbi implements AccountService {

    <strong i="11">@Override</strong>  
    <strong i="12">@Transaction</strong>  
    public final void addAccount(@BindBean() Account account, User user) {
        long accountId =  accountDao().insertAccount(account);
        accountDao().linkAccountToOwner(accountId, user.getId());
    }

    <strong i="13">@CreateSqlObject</strong>
    abstract AccountDao accountDao();
}

（あなたはダオを想像することができます）

これにより、複数のDAOメソッドを介したトランザクションを可能にしながら、ロジックとデータアクセスを非常にうまく分離できます。 サービスの単体テストは、DAOインターフェースを実装することにより、簡単に記述および理解できます。

JDBI 3でも同様のことを試みましたが、サービスクラスの実装は、ロジックを含むメソッドのデフォルトメソッドとのインターフェイスである必要があることを意味すると思います。 デフォルトのメソッドをfinalにすることはできないため、コードは簡潔ではなく、クラスの使用方法をあまり制御できません。

JDBI 3でコードを構造化して、最終的なトランザクションメソッドを作成する方法はありますか？

インターフェイスメソッドをfinalとして定義する方法がないことは正しいです。

ただし、 @SqlQuery 、 @SqlUpdateなどと同等の独自のSQLメソッドアノテーションを定義し、そのアノテーションを持つメソッドの静的実装を提供することはできます。

ただし、 @SqlQuery 、 @SqlUpdateなどと同等の独自のSQLメソッドアノテーションを定義し、そのアノテーションを持つメソッドの静的実装を提供することはできます。

返信ありがとうございます-私はそれが私をどのように助けるかについては完全にはフォローしていません。 複数のDAOでクエリを実行しながら、同じトランザクションでクエリを実行するための推奨される方法は何ですか？

複数のDAOでクエリを実行するが、同じトランザクションでクエリを実行する方法はありますか？

個人的には

interface Dao1 {
  @SqlQuery("...")
  void query1();
}

interface Dao2 {
  @SqlQuery("...")
  void query2();
}

interface JdbiServiceImpl extends Service {
  <strong i="8">@CreateSqlObject</strong>
  Dao1 dao1();
  <strong i="9">@CreateSqlObject</strong>
  Dao2 dao2();

  <strong i="10">@Transaction</strong>
  <strong i="11">@Override</strong>
  void businessCase() {
    dao1().query1();
    dao2().query2();
  }
}

Service service = handle.attach(JdbiServiceImpl.class);
service.businessCase();

このように私にとっては素晴らしい働きをします。 @CreateSqlObjectは基本的に、getter / setterによるSpringの依存性注入に似ています。 私はonDemandインスタンスをBeanとしてSpringコンテキストに配置しているため、通常のサービスとまったく同じように機能します。呼び出し元はjdbiや実装インターフェイスについて知る必要はありません。

表示されるアンチパターンのようなStockReductionCaseは、CreateSqlObjectを使用したネストされたjdbiの「依存性注入」の例です。 サービスの実装と同じように、内部に独自の依存関係があります。 これは基本的にそれ自体がサービスです。サービス（トップレベルの再利用不可能なロジック）とクエリのいずれかにCases（複数の場所で必要）を配置するだけで循環依存を回避するために、ServiceではなくCaseと呼びます。

特にonDemand()と組み合わせると、トランザクションを@CreateSqlObjectで正しくスコープすることに成功したというさまざまな報告を聞いたことがあります。

同じトランザクションで複数のSQLオブジェクトを実行する最も確実な方法は、 Handle.inTransaction()またはJdbi.inTransaction()を介してトランザクションを実行することです。 コールバック内では、 Handle.attach()を介して作成されたDAOは、ハンドルのトランザクションの一部になります。

jdbi.useTransaction(handle -> {
  Dao1 dao1 = handle.attach(Dao1.class);
  Dao2 dao2 = handle.attach(Dao2.class);

  dao1.doStuff();
  dao2.doMoreStuff();
});

返信ありがとうございます
@qualidafialこれは私が行かなければならない方法のように見えますが、サービスクラスの単体テストを作成するのは難しくなります。 Daos自体をインスタンス化するため、単体テストの代わりにモックDaosを使用することはできません。

@TheRealMarnesにも感謝します-これは私が試したものと似ていますが、デフォルトのメソッドを使用するのは好きではありません。オーバーライドできるからです。

@qualidafial複数のdaoメソッドを呼び出すサービスメソッドでjdbiの@Transactionアノテーションを使用できないことを確認したいと思いますか？

この仮定が正しければ、公式文書の一部として適切に文書化されていないと、この動作は非常に危険です。 多数の開発者がSpringスタックの経験があり、 @Transactionalアノテーションを使用することは、複数のDAO間のトランザクションをサポートするための非常に標準的な方法です。

@svlada @TransactionアノテーションはSQLオブジェクトのメソッドでのみ機能します。 「サービスメソッド」と言うと、Jdbiの影響を受けないオブジェクト、たとえば注入されたクラスにアノテーションを使用しているという印象を受けます。

テストスイートの例：

<strong i="9">@Test</strong>
public void testInsertAndFind() {
    Foo foo = handle.attach(Foo.class);
    Something s = foo.insertAndFind(1, "Stephane");
    assertThat(s).isEqualTo(new Something(1, "Stephane"));
}

<strong i="10">@Test</strong>
public void testTransactionPropagates() {
    Foo foo = dbRule.getJdbi().open().attach(Foo.class);

    assertThatExceptionOfType(Exception.class)
        .isThrownBy(() -> foo.insertAndFail(1, "Jeff"));

    Something n = foo.createBar().findById(1);
    assertThat(n).isNull();
}

public interface Foo {
    <strong i="11">@CreateSqlObject</strong>
    Bar createBar();

    @SqlUpdate("insert into something (id, name) values (:id, :name)")
    int insert(@Bind("id") int id, @Bind("name") String name);

    <strong i="12">@Transaction</strong>
    default Something insertAndFind(int id, String name) {
        insert(id, name);
        return createBar().findById(id);
    }

    <strong i="13">@Transaction</strong>
    default Something insertAndFail(int id, String name) {
        insert(id, name);
        return createBar().explode();
    }
}

public interface Bar {
    @SqlQuery("select id, name from something where id = :id")
    Something findById(@Bind("id") int id);

    default Something explode() {
        throw new RuntimeException();
    }
}

onDemand() + @CreateSqlObjectについても明確にしておきたい：

• @CreateSqlObject DAOは、上記の例のように、それらを作成したDAOの内部メソッドからのみ使用できます。
• fooDao.createBar().findById()を呼び出すと、接続が閉じられたことを示す例外がスローされます。

もう一度コメントしてすみません。 これに役立つロードマップに何かありますか？

抽象クラスでCreateSqlObjectを使用できるのはまだ本当に寂しいです。 インターフェイスですべてを実行する必要があることは、依然として制限を感じます。 多くの場合、「サービス」タイプのメソッドをトランザクションにしたいのですが、これは、サービスクラスもデフォルトのメソッドを使用するインターフェイスである必要があり、関心の分離、具体的な最終メソッドなどの明確さが失われ始めることを意味します。

@tamslinn抽象クラスではなくインターフェースの問題に関する限り、近い将来、その決定から戻ってくることはないと私は安全に言えると思います。 Jdbi3は、インターフェースのみをサポートするjdkプロキシを使用します。

cglibに基づいて構築された、この機能を提供する別のモジュールが提供されていることは完全に問題外ではないと思いますが、現時点では問題ではありません。

sqlobjectの公理がそれに合わない場合は、いつでもサービスをリファクタリングして、jdbiによって拡張されていない通常のクラスにすることができますが、代わりに流暢なAPIを使用するためにJdbiインスタンスを注入することができます。

トランザクションサポートやオンデマンドなどの本来の振る舞いについては、まだ具体的な計画はないと思いますが、ますます注目が集まっています。 しかし、私たちはそれに到達しています。

アップデートしていただきありがとうございます。 プロキシに関しては完全に理にかなっています。
私にとっての特定の制限は、JDBIクラスの外部でトランザクションを開始/終了できないことです。
（ @svladaが述べたように、他のフレームワークでは、より高いレベルで@Transactionalを使用するのが非常に一般的です）
私はJDBIの他のすべてが本当に好きなので、それを維持します。おそらく、サービスクラスに満足しているデザインパターンを思い付くでしょう:)

もう一度コメントしてすみません。 これに役立つロードマップに何かありますか？

全く問題無い。 これは明らかに混乱の原因であり、修正したいことがあります。前回はしなかったので、今回は確実に正しく修正したいと思います:)

（ @svladaが述べたように、他のフレームワークでは、より高いレベルで@Transactionalを使用するのが非常に一般的です）

ええ、でも私が理解している限り、それはすべてDIフレームワーク（Springなど）のAOPフックを介して行われます。 JDBIはすべてのサービスオブジェクトを「ラップ」するわけではないため、自分で作成していないオブジェクトにAOPのようなソリューションを提供する機会はありません。 古いcglib実装でさえ、daos自体の@Transactionalにしか気付かず、別のサービスクラスで機能することはありませんでした。

役立つ場合は、SpringやGuiceのAOPバインディングを追加して、より高いレベルのトランザクションを許可することを検討できます。 これはcoreの一部ではなく、たとえばspring拡張機能の一部になります。 これはコア開発者が飛びつくようなものではないでしょうが、貢献は真剣に含まれると考えられます。 多分それはあなたの問題を「よりクリーンな」方法で解決しますか？

主に互換性の理由から、 cglibからProxyに切り替えることにしました- Proxyはサポートされているjdk apiですが、 cglib （またはより具体的asm ）は、メジャーリリース（8、9、11、...で壊れた）ごとに壊れる傾向があり、これは大きなメンテナンスの頭痛の種になります。

たぶんhttps://github.com/jdbi/jdbi/pull/1252は関係がありますか？

こんにちは、

情報@stevenschlanskerをありがとう。 私は現在のプロジェクトで実際にSpringとJDBIを使用していませんが、比較のために言及されました。 私はAOPのことを完全に理解しています。それを回避する方法を見つけようとしているだけです。つまり、コードを好きなように分割できます。これは、以前は抽象クラスでしたが、 cglibから離れることは完全に理にかなっています。

今は、必要なときにサービスクラスを作成するだけで、トランザクション内でサービスクラスを作成できるようになると考えています。

         try (Handle handle = jdbi.open()) {
                handle.useTransaction(h -> {
                    AccountService accountService = new AccountServiceImpl(h.attach(AccountDao.class));                    
                    accountService.addAccount(a, u);
                });
          }

これは、Mock Daoを使用してサービスを単体テストし、サービスメソッドを最終的に維持し、トランザクション管理のインターフェイスのデフォルトメソッドに依存しないことを意味すると思います。また、サービスクラスのインスタンス化の追加オーバーヘッドが大きな影響を与えることはありません。

最後のコメントのコード例に簡単に返信してくださいtryブロックをスキップして、$ jdbi.useTransaction()を直接呼び出すことができます。 このメソッドは、コールバックが戻ったときに自動的に閉じられる一時的なハンドルを割り当てます。

みなさん、こんにちは。PR＃1579があります。jdbi3.10.0の時点で、CreateSqlObjectとonDemandは（最終的に）うまく連携するはずです。