안녕하세요! 유익한 강의 감사합니다. Executor 설명 중 한 가지를 정정드리고 싶습니다. 강의에서 설명해주신 내용은 maxPoolSize까지 바로 스레드가 생성되는 것으로 이해될 수 있는데, 실제 동작은 먼저 corePoolSize만큼 스레드를 생성하고, 그 이후 요청은 큐에 쌓이며, 큐가 가득 찼을 때 maxPoolSize까지 확장되는 구조입니다. 물론 강의 흐름상 의도적으로 설명을 단순화하신 것일 수도 있습니다만, 혼동될 수 있는 부분이라 참고용으로 댓글 남깁니다!
강의 내용에 실습 영역을 따라 스크립트를 작성하였는데 데이터베이스가 보여지지 않습니다. 맥, 윈도우 모두 동일한 상태라 별도로 db를 다운받아 워크벤치 넣어야되는 것인지 문의 드립니다. - 강의 영상에 대한 질문이 있으시면, 상세히 문의를 작성해주시면, 주말/휴일 제외, 2~3일 내에 답변드립니다 (이외의 문의는 평생 강의이므로 양해를 부탁드립니다.) - 강의 답변이 도움이 안되셨다면, dream@fun-coding.org 로 메일 주시면 24시간 내에 재검토하겠습니다. - 괜찮으시면 질문전에 챗GPT 와 구글 검색을 꼭 활용해보세요~ - 잠깐! 인프런 서비스 운영(다운로드 방법포함) 관련 문의는 1:1 문의하기를 이용해주세요.
안녕하세요, 강사님 덕분에 많은 인사이트를 얻으며 성장중인 수강생입니다ㅎㅎ 다름이 아니라 이벤트 페이로드 타입의 생성 방식이 팩토리 메서드 패턴이 아닌 빌더 패턴인 이유가 궁금합니다! 빌더 패턴의 장점은 생성자 오버로딩이 많을 때, 간편하게 사용할 수 있다는 장점이 있지만 필수인 필드에 null 이 들어갈 수 있다는 단점이 있다고 생각합니다. 그래서, 저는 빌더 패턴을 해당 객체의 필드 중 null 이 들어갈 수 있는 필드가 많을 때 사용하는 걸 선호하다 보니, 이벤트 페이로드 타입을 생성 할 때 일부 필드에 null 이 들어가는 걸까? 란 궁금증으로 질문이 생기게 되었습니다. 빌더 패턴에 대한 강사님의 의견이 궁금하며 이벤트에 기존에 사용하신 팩토리 메서드 대신 빌더 패턴을 사용하신 계기가 궁금합니다! 감사합니다 :)
학습 관련 질문을 최대한 상세히 남겨주세요! 고민 과정도 같이 나열해주셔도 좋습니다. 먼저 유사한 질문이 있었는지 검색해보세요. 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. [33. 좋아요 수 구현] 에서 테스트 하는 화면에서요. 해당 방법대로 실행을 하면 동시성 문제가 발생합니다. Record has changed since last read in table 'article_like_count' 저는 MariaDB를 사용하고 있는데요. MySQL도 마찬가지로 기본 잠금 수준이 Repeatable Read 라고 알고 있습니다. 해당 기본 수준으로 실행하면 동시성 문제로 영상과 다른 결과를 보이게 됩니다. 따라서 잠금 수준을 Read Commited 나 Read Uncommited 로 변경하면 제대로 실행이 됩니다. 이렇게 하는 것이 정답인지 아니면 다른 원인이 있는건지 알려주세요.
학습 관련 질문을 최대한 상세히 남겨주세요! 고민 과정도 같이 나열해주셔도 좋습니다. 먼저 유사한 질문이 있었는지 검색해보세요. 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. @Query("select c from CommentV2 c where c.commentPath.path = :path") Optional<CommentV2> findByPath(@Param("path") String path); 위와 같은 방식으로 조회를 하면 인덱스 서치가 되지 않는 것 아닌가요? 아래와 같은 방법으로 해야 할 것 같은데.. @Query("select c from CommentV2 c where c.articleId = :articleId and c.commentPath.path = :path") Optional<CommentV2> findByPath( @Param("articleId") Long articleId, @Param("path") String path); 답변 부탁 드립니다.
문제에서 populations larger than 100000 <- 여기서 larger than 이 10만 보다 큰 그러니까 10만을 초과하는게 아니라 10만을 포함한 10만 이상되는 도시 출력하는게 맞는건가요?? 10만보다 큰 으로 해석해서 where절에서 where population > 100000 으로 썼었거든요
입문자를 위한 Spring Boot with Kotlin - 나만의 포트폴리오 사이트 만들기
안녕하세요, 윈도우 환경에서 작업중입니다. 다름이 아니라 Gradle을 IDEA로 변경하면 Build 시에 Error가 떠서 AI에게 물어보니 Gradle로 변경하라 하여 변경하니 되는데 이렇게 작업해도 상관 없는 부분일까요? 오류메세지: Kotlin: [Internal Error] java.lang.NoClassDefFoundError: org/jetbrains/kotlin/com/intellij/psi/PsiElement at org.jetbrains.kotlin.noarg.fir.KtErrorsNoArg.<clinit>(KtErrorsNoArg.kt:32) at org.jetbrains.kotlin.noarg.fir.FirNoArgExtensionRegistrar.configurePlugin(FirNoArgExtensionRegistrar.kt:15) at org.jetbrains.kotlin.fir.extensions.FirExtensionRegistrar.configuredExtensionFactories_delegate$lambda$0(FirExtensionRegistrar.kt:294) at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:86) at org.jetbrains.kotlin.fir.extensions.FirExtensionRegistrar.getConfiguredExtensionFactories(FirExtensionRegistrar.kt:291) at org.jetbrains.kotlin.fir.extensions.FirExtensionRegistrar.configure(FirExtensionRegistrar.kt:270) at org.jetbrains.kotlin.fir.session.FirAbstractSessionFactory.createSharedLibrarySession(FirAbstractSessionFactory.kt:107) at org.jetbrains.kotlin.fir.session.FirJvmSessionFactory.createSharedLibrarySession(FirJvmSessionFactory.kt:53) at org.jetbrains.kotlin.cli.pipeline.jvm.JvmFrontendPipelinePhase.prepareJvmSessions$lambda$0(JvmFrontendPipelinePhase.kt:326) at org.jetbrains.kotlin.cli.common.SessionConstructionUtils.prepareSessions(FirSessionConstructionUtils.kt:324) at org.jetbrains.kotlin.cli.pipeline.jvm.JvmFrontendPipelinePhase.prepareJvmSessions(JvmFrontendPipelinePhase.kt:322) at org.jetbrains.kotlin.cli.pipeline.jvm.JvmFrontendPipelinePhase.executePhase(JvmFrontendPipelinePhase.kt:137) at org.jetbrains.kotlin.cli.pipeline.jvm.JvmFrontendPipelinePhase.executePhase(JvmFrontendPipelinePhase.kt:47) at org.jetbrains.kotlin.cli.pipeline.PipelinePhase.phaseBody(PipelinePhase.kt:68) at org.jetbrains.kotlin.cli.pipeline.PipelinePhase.phaseBody(PipelinePhase.kt:58) at org.jetbrains.kotlin.config.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:102) at org.jetbrains.kotlin.backend.common.phaser.CompositePhase.invoke(PhaseBuilders.kt:22) at org.jetbrains.kotlin.config.phaser.CompilerPhaseKt.invokeToplevel(CompilerPhase.kt:53) at org.jetbrains.kotlin.cli.pipeline.AbstractCliPipeline.runPhasedPipeline(AbstractCliPipeline.kt:109) at org.jetbrains.kotlin.cli.pipeline.AbstractCliPipeline.execute(AbstractCliPipeline.kt:68) at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecutePhased(K2JVMCompiler.kt:79) at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecutePhased(K2JVMCompiler.kt:45) at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:90) at org.jetbrains.kotlin.cli.common.CLICompiler.exec(CLICompiler.kt:352) at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1617) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:569) at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360) at java.rmi/sun.rmi.transport.Transport$ 1.run (Transport.java:200) at java.rmi/sun.rmi.transport.Transport$ 1.run (Transport.java:197) at java.base/ java.security .AccessController.doPrivileged(AccessController.java:712) at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196) at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587) at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828) at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705) at java.base/ java.security .AccessController.doPrivileged(AccessController.java:399) at java.rmi/sun.rmi.transport.tcp.TCPTransport$ ConnectionHandler.run (TCPTransport.java:704) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$ Worker.run (ThreadPoolExecutor.java:635) at java.base/ java.lang.Thread.run (Thread.java:840) Caused by: java.lang.ClassNotFoundException: org.jetbrains.kotlin.com .intellij.psi.PsiElement at java.base/ java.net .URLClassLoader.findClass(URLClassLoader.java:445) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:592) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525) ... 42 more
Q. SQL 로 미리 테이블 작성하거나 인덱스 설정을 SQL 로 직접하는데 이유가 궁금합니다 인덱스 같은경우 jpa 에서 쓸수있는 옵션이 제한적이라 따로 SQL 로 관리한다고 듣긴했는데 테이블도 실제로 SQL 에서 하는지 궁금하고, SQL 로만 테이블 생성 인덱스 관리를 할경우 현업에서는 어떤 db 마이그레이션 라이브러리를 주로 사용하는지도 궁금합니다. Q. 참조관계를 DB 에서 걸지않고 논리적으로만 걸었을때 참조테이블에대한 조인은 어떤식으로 하는지 궁금합니다. MSA 기준으론 데이터베이스가 아예 분리될텐데 어떤식으로 조인하나요? 추가적으로 논리적으로 참조설계가 된 상황에서 @ManyToOne 사용이 가능한지궁급합니다. 예를들면 Comment 엔티티에서 parentCommentId 같은 같은 데이터베이스에 있는 테이블에 @ManyToOne 적용이 가능한지궁급합니다.
안녕하세요! 강의를 모두 학습하고, 실습도 진행하면서 오케스트레이션 방식을 적용해보고 있는데 궁금한 점이 있어 질문드립니다. 현재 실습 환경에서는 service_1 이 단일 진입점 역할을 하면서 Account 관련 로직까지 함께 처리하고 있습니다. 그런데 실무에서는 이 두 역할을 분리하는 것이 맞는지 고민되고 있습니다. 제가 생각하기로는, 명확한 Orchestrator 서비스가 존재하지 않으면 각 서비스가 상황에 따라 오케스트레이션 역할을 맡게 되고, 시간이 지나면서 구조가 복잡해지고 유지보수에 많이 불리할 것 같습니다. 그래서 실제 운영 환경에서는 다음과 같은 구조가 더 적절한지 여쭙고 싶습니다. orchestration-service → account-service → ... 즉, 오케스트레이션만 담당하는 서비스를 별도로 두고, 각 도메인 서비스는 자신의 책임만 수행하도록 설계하는 것이 맞을까요? 좋은 강의 감사합니다! 많이 배우고 있습니다!
현재 JWT 부분까지 들었습니다! 강의를 들으면서 갑자기 궁금한 부분이 생겨 질문드립니다. 도메인 별로 현재 API (Controller) 도 나눠져있는데요, 이런 형태의 프로젝트(DDD 아키텍처)인 경우 @RestControllerAdvice를 활용한 글로벌예외처리는 어떻게 구성하시나요? 글로벌예외처리 전용 class를 만들고 특정 익셉션들을 구성 후 각각의 익센션에 대한 응답을 ResponseProvider 를 이용해서 하는지? 등... 너무 추상적으로 질문을 드려서 이해하실지 모르겠지만 요약하자면 도메인별로 구별되어 있는 프로젝트에서는 글로벌익셉션처리가 어떤 형태로 구성할 수 있는지 궁금합니다 ㅋ.ㅋ;
안녕하세요 강의 열심히 보고 분산트랜잭션에 대해 배워가고 있습니다. 우선 좋은 강의 만들어주셔서 감사합니다. 강의를 보다가 OrchestrationService 소스 코드 설명해주시는 부분에서 궁금증이 생겨 질문드렸습니다. 현재 하나의 트랜잭션 내에서 출금처리에 대한 로컬 트랜잭션 처리 + 입금 서비스 REST 호출 + 입금 서비스 응답이후 SAGA 상태 업데이트 까지 처리하고 있는 것으로 보입니다. 이 경우에 입금 서비스에서 응답이 지연된다면 출금계좌에 대한 락은 지연시간만큼 대기를 하게 되고 트래픽이 몰리는 상황에서는 처리 성능이 떨어질것 같다고 판단했습니다. 그래서 제 생각에는 입금 서비스 호출 이전, 입급 서비스 호출 후 응답값에 대한 saga 업데이트, 출금 서비스 보상 처리 이렇게 3개의 로직을 각각 별개의 트랜잭션으로 선언해야 하지 않나 싶은데, 강사님의 의견이 궁금합니다!