Spring

자바 플랫폼을 위한 오픈소스 애플리케이션 프레임워크로서 엔터프라이즈급 애플리케이션을 개발하기 위한 모든 기능을 종합적으로 제공하는 경량화된 솔루션입니다.엔터프라이즈급 개발이란 뜻대로만 풀이하면 기업을 대상으로 하는 개발이라는 말입니다. 즉, 대규모 데이터 처리와 트랜잭

Bean Scope 는 말 그대로 빈이 존재할 수 있는 범위를 뜻합니다. 스프링은 다음과 같은 다양한 스코프를 지원합니다.기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프입니다.스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만

JDBC : SQL 쿼리를 많이 작성해야하고 자바 코드도 많이 작성Spring JDBC : SQL 쿼리를 많이 작성하는데 자바 코드는 적게 작성JPA : 쿼리를 신경 쓸 필요가 없음(작성x, 직접 테이블로 바로 매핑 가능)spring data JPA : 코드의 양이 적

JPA를 활용하게 되면 Corse Bean을 데이터베이스에 존재하는 테이블로 직접 매핑✅ Course 클래스@Entity 를 사용히여 테이블과의 직접 매핑@Entity 가 붙은 클래스는 JPA가 관리 기본 생성자는 필수(JPA가 엔티티 객체 생성 시 기본 생성자를 사용

자바 서블릿은 자바를 사용하여 웹 페이지를 동적으로 생성하는 서버 측 프로그램 또는 그 사양을 말하며, 흔히 서블릿이라고 불립니다. 즉 서블릿은 클라이언트 요청을 처리하고, 그 결과를 반환하는 웹 프로그래밍 기술입니다.1\. 사용자가 Client(브라우저)를 통해 서버

쿠키와 세션 모두 HTTP 에 상태 정보를 유지(Stateful)하기 위해 사용됩니다. 즉, 쿠키와 세션을 통해 서버에서는 클라이언트 별로 인증 및 인가를 할 수 있게 됩니다.클라이언트에 저장될 목적으로 생성한 작은 정보를 담은 파일개발자 도구에서 클라이언트인 웹 브라

블로그를 찾아보면서 다른 분들이 구글을 많이 이용하셨길래 나도 구글 이메일인증을 사용해보기로 하였다.먼저 구글에 로그인을 진행한다. 1 ) 구글 홈페이지 오른쪽 상단에 본인 프로필 클릭2 ) Google 계정관리 클릭3 ) 보안 - 검색창에 앱 비밀번호 검색보안 - 검

하이버네이트 쿼리 언어의 쿼리를 타입에 안전하게 생성 및 관리해주는 프레임 워크Query DSL 은 정적 타입을 이용하여 SQL 과 같은 쿼리를 생성할 수 있게 해준다. 자바 백엔드 기술은 Spring Boot와 Spring Data JPA를 함께 사용한다. 하지만,

select 대상을 지정프로젝션 대상이 하나면 타입을 명확하게 지정할 수 있음 프로젝션 대상이 둘 이상이면 '튜플' 이나 DTO로 조회순수 JPA 에서 DTO 조회Member DTO순수 JPA에서 DTO를 조회할 때는 new 명령어를 사용해야함 DTO의 package이

MemberTeamDto - 조회 최적화용 DTO 추가참고: @QueryProjection 을 사용하면 해당 DTO가 Querydsl을 의존하게 된다. 이런 의존이 싫으면, 해당 에노테이션을 제거하고, Projection.bean(), fields(), construc

1\. Offsetoffset(어디서부터?), limit(몇개를?)SELECT ...FROM ...WHERE ...ORDER BY id DESCOFFSET {page_number}LIMIT {page_size}offset 은 pageNumber 에 해당하는 행만큼 데

검색 결과 (DSL 사용 X): 100 StopWatch '': 0.252218666 secondsQuerydsl 실행시간 측정 : 75ms

37ms0.5ms10만개로 많은 데이터는 아니었지만 QueryDSL 을 사용하였을 때 JPA보다 속도측면에서 이점이 더 많다는 것을 알 수 있었던 유의미한 테스트였다.

연관된 데이터를 즉시 로딩하기 위해 사용, 이를 사용하면 하이버네이트는 연관된 데이터를 함께 가져오도록 쿼리문을 생성, 나중에 접근할 때 발생할 수 있는 추가쿼리를 방지post 엔티티와 관련된 user 엔티티를 패치조인으로 연결, post 데이터를 로드할 때 관련된 u

두 방법의 차이와 성능 차이를 비교하면서 내가 어떤 방법을 택했는지 보자먼저 ElasticSearch + QueryDSL 을 사용하여 구현하였을 때의 흐름은 다음과 같다. 1\. 클라이언트가 입력한 contents 에 해당하는 게시물을 es 에서 검색, 이때 es 에

AWS S3 업로드 게시물 생성 서비스 로직

Could not connect to Redis at 127.0.0.1:6379: Connection refused

약 6주간 FE 2명, BE 4명, 디자이너 1명으로 팀을 구성하여 프로젝트를 진행하였다. 나는 백엔드 파트와 팀장을 맡아 프로젝트를 진행하였다.”동네 방네”는 줄어든 동네에 대한 애정, 주민들과의 유대감을 증대시키기 위한 서비스입니다.동네방네는 "동네를 꾸며간다” 에

1\. 브라우저로 부터 Dispatcher Servlet 이 요청을 받습니다.2\. Dispatcher Servlet 은 요청받은 URL 을 Handler Mapping 에 넘겨주고 적합한 Controller 를 찾습니다.3\. Handler Adapter 를 통해 해

🔗 깃허브 링크Cache란 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. 캐시는 저장 공간이 작고 비용이 비싼 대신, 매우 빠른 성능을 제공한다는 장점이 있다.이와 같이 캐시는 웹 서비스 환경, 엔터프라이스급 개발 환경에서 DBMS 의 부하를

동시성 문제 해결을 위해 강의를 들으며 docker 를 실행하기전 docker version 을 터미널에 입력하였는데 이라는 메시지가 나왔다.먼저 docker desktop 을 실행시키고 하지 않았기 때문에 desktop 을 실행시켰다.docker 에 mysql 을 실

👨🏻‍💻 참고강의프로젝트를 하면서 발생할 수 있는 동시성 문제에 대해서 알아보고, 어떻게 해결할 수 있는지 알아보기 위해 글을 작성한다. 자료는 위의 강의를 참고하였습니다. 여러 자원에 대해 프로세스 또는 스레드가 동시에 접근하면서 발생하는 문제그렇다면 어떤 경우

동시성문제(1) 에서 동시성문제가 무엇이고 왜 일어나는지 알아보았다. 이번 포스트에서는 자바의 synchronized 를 사용하여 동시성 문제를 해결할 수 있는지, 어떻게 적용하는지 알아보겠다. 여러개의 스레드가 한개의 자원을 사용하고자 할 때,현재 데이터를 사용하고

저번 포스트 동시성문제(2) 에서는 자바의 synchronized 를 사용하여 동시성 문제를 해결할 수 있는지, 어떻게 적용하는지 알아보았다. 이번에는 락을 통해 synchronized 로는 해결하지 못하는 문제를 어떻게 해결할 수 있는지 알아보겠다. 여러 커넥션에서

저번 포스트 동시성문제(3) 에서는 자바의 비관적 락으로 어떻게 동시성 문제를 해결할 수 있는지, 어떻게 적용하는지 알아보았다. 이번에는 낙관적 락을 통해 문제를 어떻게 해결할 수 있는지 알아보겠다. 1. 낙관적 락 > 현실적으로 데이터 갱신 시 경합이 발생하지 않을

저번 포스트 동시성문제(4) 에서는 낙관적 락으로 어떻게 동시성 문제를 해결할 수 있는지, 어떻게 적용하는지 알아보았다. 이번에는 Named 락을 통해 문제를 어떻게 해결할 수 있는지 알아보겠다.이름을 가진 메타데이터 락비관적 락과 비슷하다. 하지만 비관적락은 row

유저가 대기열에 진입하지 않은 경우:유저가 좌석 조회를 시도.서버가 대기열에 진입하지 않았음을 확인하고, 대기열 토큰 발급을 안내.유저가 대기열에 진입하여 대기열 토큰을 발급받은 후 좌석 조회 API를 호출.→ 잘못 생각한 부분 ( 수정 ) 유저는 바로 대기열에 진입한

token 을 Interceptor 에서 찾을 때, request.getParam("") 이 아닌 request.getHeader("") 로 하여 컨트롤러에서 @RequestParam String token 을 사용하지 않도록 변경해야겠다고 생각. 어짜피 Interce

< 프로세스 >유저 등록 → 대기열 진입( 대기열 토큰 발급 ) → 예약 → 콘서트 결제 or 잔액 충전 및 조회 → 완료여러 스레드가 동시에 공유 자원에 접근할 때 발생하는 문제이다. 이는 데이터의 일관성을 해칠 수 있다.EX ) 은행 계좌에 두 사람이 동시에

저번 포스트에서는 내가 구현하고 있는 프로젝트에서 어떠한 동시성 문제가 생길 수 있을까에 대해 고민해보았다. 나는 결제에 대해서는 많은 접근이 일어나지 않을 것이라고 판단하였고 때문에 성능적으로 더 이점을 줄 수 있는 낙관적 락을 채택하였다.(통합테스트 통과 못해서 힘

동시성 문제와 함께 다량의 트래픽을 처리하기 위해 어떻게 DB 에 적은 부하를 주면서 기능을 구현할 수 있을까?데이터를 임시로 복사적은 부하로 API 응답을 빠르게 처리할 수 있다.우리 주변에서 볼 수 있는 Cache 사례DNS : 웹사이트 IP 를 기록해두어 웹사이트

유저생성 콘서트 생성 이벤트 생성 대기열 생성 예약 생성 잔액 충전 잔액 조회 콘서트 결제

내 로직에서 어떤 부분에 인덱스를 사용하여 쿼리성능을 향상시킬 수 있을까? 현재 나의 주요 로직들을 실행하였을 때 발생하는 쿼리들을 가져와보았다. (길기 때문에 글 맨 아래에 첨부해두었다.) 💡 발생하는 쿼리 유저생성 콘서트 생성 이벤트 생성 대기열 생성

스프링 프레임워크에서는 @Transactional 사용하면 아주 편하게 트랜잭션을 활용할 수 있다.트랜잭션 범위안에 있는 모든 DB 요청들은 하나의 커넥션을 공유하기 때문에 성능도 높일 수 있고, 한 메서드안에서 동작하는 다른 메서드들이 하나만 성공하고 하나만 실패하는

트랜잭션 내에서 핵심 비즈니스 로직을 처리하고, 트랜잭션이 성공적으로 커밋된 후에 별도의 비동기 작업을 수행하여 시스템의 관심사를 분리하는 이벤트 기반 아키텍쳐를 만들어보자.이벤트(Event) : 시스템 내에서 발생하는 중요한 상태 변화나 활동을 나타내는 메시지이벤트

이벤트 기반 아키텍처를 알아보자

어느 개발자의 Docker 여정기.. 눈물을 머금고 시작..

부하테스트,, 너 왜 안돼?

저번 [콘서트 예약 시스템] - 인덱스 적용 게시물 작성 당시