Jdbi: @CreateSqlObject를 덜 혼란스럽게 만듭니다.

신고해 주셔서 감사합니다. 여기에서 기술적으로 주요 변경 사항이 있을 것으로 생각하지만 기존 동작이 3.x 릴리스 주기의 초기에 기술적으로 주요 변경 사항을 만들 만큼 충분히 좋지 않다고 생각합니다. 기존 동작에 의존하거나 잠재적으로 작은 주요 변경 사항을 여기에 제공하는 데 동의하지 않는 경우 이 문제에 플래그를 지정하십시오.

@CreateSqlObject 가 온디맨드에서 잘 작동하지 않는 _이유_에 대한 컨텍스트:

• 주문형은 프록시를 사용하여 구현되는 핵심 수준의 추상화입니다. 요청 시 프록시에서 메서드를 호출하면 실제 SQL 개체가 생성되고 메서드 호출이 실제 SQL 개체에 위임됩니다. 대리자 메서드 호출이 반환된 후 해당 실제 인스턴스를 지원하는 핸들이 닫힙니다.
• @CreateSqlObject 는 handle.attach(sqlObjectType) 를 사용하여 구현되며 원래 SQL 개체의 지원 핸들이 있습니다.

따라서 생성된 SQL 개체에 대한 지원 핸들은 SQL 개체가 반환되기 전에 닫힙니다.

위의 어느 것도 확정된 것은 아니며 현재 구현된 방식입니다.

나는 우리가 이 문제를 해결하기 위해 호환성을 깨야 할 것이라고 확신하지 않습니다.

죄송합니다. 잘 이해가 되지 않습니다... onDemand 및 CreateSqlObject의 문제는 정확히 무엇입니까? 나는 그것에 대해 아무런 문제가 없었고 @qualidafial 의 설명에 대한 무언가가 내 마음을 기울게 만듭니다 ...

fooProxy.usecase 에 대한 호출에 대한 연결이 확보됩니다. Foo.usecase 는 현재( usecase 의) 핸들에 연결한 후 새 Bar 를 반환하는 createSqlObject 메서드를 호출합니다. usecase 가 반환되면 usecase 의 핸들이 닫힙니다. 반환된 Bar 와 비동기식으로 아무것도 하지 않는 한 어떻게 bar 의 핸들이 너무 일찍 만료될 수 있습니까? bar 의 수명 주기와 사용은 핸들과 마찬가지로 Foo.usecase 의 본문으로 제한됩니다.

JDBI 내부에 대해 말할 수는 없지만 프로덕션에서 본 동작에 대해서는 언급할 수 있습니다.

기본적으로 우리의 낮은 환경에서는 괜찮았습니다. 그러나 프로덕션의 로드가 증가함에 따라 적절한 데이터베이스 노드에 대해 SQL 문이 실행되지 않는 것을 계속 보게 됩니다. 예를 들어 읽기 전용 선택은 마스터 노드에 도달하고 삽입은 읽기 전용 복제본에 도달합니다. 또한 작업 도중에 연결 닫힘 오류가 발생했습니다.

본질적으로 @CreateSqlObject 가 스레드 안전 문제를 만든 것 같습니다. 읽기 전용 플래그가 경쟁 요청에 의해 변경되는 경우입니다.

문제를 "해결"하기 위해 @CreateSqlObject 의 모든 사용을 제거하고 다음과 같이 끝냈습니다.

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

그런 다음 우리는 jdbi.onDemand(CombinedDao) 를 사용하고 이를 통한 액세스만 사용합니다.
그 패턴으로 전환하면 예쁘지는 않지만 앞서 언급한 프로덕션 오류가 모두 제거되었습니다.

정보를 위해, 제 모든 코드가 현재 추상 클래스와 함께 onDemand를 사용하기 때문에 JDBI 2로 돌아갈 생각입니다. 그리고 제가 만족할 방식으로 재구성하는 방법을 알아낼 수 없습니다!

저는 순수 SQL인 DAO 클래스에 대한 액세스를 제공하기 위해 CreateSqlObject를 사용하여 트랜잭션으로 주석이 달린 메서드를 사용하여 논리를 포함하지만 SQL은 포함하지 않는 추상 구현 클래스가 있는 서비스 인터페이스를 사용하는 경향이 있습니다. 단순화된 예:

상호 작용

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 메소드를 통한 트랜잭션을 허용하면서 로직과 데이터 액세스를 아주 훌륭하게 분리합니다. 서비스에 대한 단위 테스트는 DAO 인터페이스를 구현하여 작성하고 이해하기 쉽습니다.

JDBI 3에서 비슷한 작업을 시도했지만 내 서비스 클래스의 구현이 논리를 포함하는 기본 메서드가 있는 인터페이스여야 한다는 것을 의미한다고 생각합니다. 기본 메서드는 최종적으로 만들 수 없기 때문에 코드가 간결하지 않고 클래스를 사용할 수 있는 방법에 대한 통제력이 떨어집니다.

최종 트랜잭션 메서드를 갖도록 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에 의한 스프링의 종속성 주입과 같습니다. 내 스프링 컨텍스트에 onDemand 인스턴스를 bean으로 두어 일반 서비스와 똑같이 작동하므로 호출자는 jdbi 또는 구현 인터페이스에 대해 알 필요가 없습니다.

당신이 보는 반패턴 모양의 StockReductionCase는 CreateSqlObject를 사용한 중첩된 jdbi "종속성 주입"의 예입니다. 서비스 구현과 마찬가지로 내부에 자체 종속성이 있습니다. 기본적으로 그 자체로 서비스입니다. 서비스(재사용 불가능한 최상위 논리) 내부에 Cases(여러 위치에 필요)와 쿼리를 둘 중 하나에 넣음으로써 순환 종속성을 피하기 위해 Service 대신 Case라고 부릅니다.

@CreateSqlObject , 특히 onDemand() 와 결합할 때 트랜잭션 범위를 올바르게 지정하는 데 성공했다는 혼합 보고서를 들었습니다.

동일한 트랜잭션에서 여러 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로 대체할 수 없습니다.

@RealMarnes 도 감사합니다. 이것은 내가 시도한 것과 비슷해 보이지만 재정의할 수 있는 기본 방법을 사용하는 것을 좋아하지 않습니다.

@qualidafial 여러 dao 메소드를 호출하는 서비스 메소드에 jdbi의 @Transaction 주석을 사용할 수 없음을 확인하고 싶습니다.

이 가정이 맞다면 공식 문서의 일부로 제대로 문서화되지 않은 이 동작은 매우 위험합니다. 많은 개발자가 Spring 스택에 대한 경험이 있고 @Transactional 주석을 사용하는 것은 여러 DAO에서 트랜잭션을 지원하는 매우 표준적인 방법입니다.

@svlada @Transaction 주석 _only_는 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를 만든 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 정보 감사합니다. 나는 실제로 현재 프로젝트에서 JDBI와 함께 Spring을 사용하지 않고 있으며, 비교를 위해 언급한 것뿐입니다. 나는 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가 있습니다 -- jdbi 3.10.0에서 CreateSqlObject와 onDemand는 (마침내) 잘 작동해야 합니다.