@Transactional(propagation = Propagation.NEVER)
@Transactional(propagation = Propagation.NEVER)는 스프링 프레임워크에서 트랜잭션 전파 수준을 설정할 때 사용하는 어노테이션입니다.
Propagation.NEVER는 현재 진행 중인 트랜잭션이 있으면 해당 메서드를 실행하지 않고 예외를 발생시킵니다. 즉, 이 설정을 사용하면 메서드가 반드시 트랜잭션 밖에서 실행되어야 하며, 트랜잭션 내에서 실행될 수 없습니다.
아래는 각 전파 속성(Propagation)의 간단한 설명입니다:
- REQUIRED: 메서드를 호출한 쪽에 트랜잭션이 있으면 해당 트랜잭션에 참여하고, 없으면 새로운 트랜잭션을 생성합니다. (기본값)
- REQUIRES_NEW: 항상 새로운 트랜잭션을 시작합니다. 기존 트랜잭션이 있다면 일시 중단됩니다.
- SUPPORTS: 트랜잭션이 있으면 참여하지만, 없으면 트랜잭션 없이 실행됩니다.
- NOT_SUPPORTED: 트랜잭션이 있어도 중단시키고, 트랜잭션 없이 실행합니다.
- MANDATORY: 호출한 쪽에 트랜잭션이 반드시 있어야 합니다. 없으면 예외를 발생시킵니다.
- NEVER: 트랜잭션이 있으면 예외를 발생시키며, 트랜잭션 없이만 실행됩니다.
- NESTED: 중첩된 트랜잭션을 시작합니다. 호출한 트랜잭션의 범위 내에서 새로운 트랜잭션이 시작됩니다.
즉, Propagation.NEVER는 메서드가 트랜잭션 내에서 실행되지 않아야 하는 상황에서 사용됩니다.
관계형 데이터베이스(RDBMS) 와 NoSQL(NotOnlySQL)
1. 관계형 데이터베이스 (RDBMS)
- 구조: 데이터는 테이블(행과 열)로 구성되어 있으며, 스키마(정해진 구조)가 엄격합니다.
- SQL 사용: 데이터를 조회하거나 조작할 때 SQL(Structured Query Language)을 사용합니다.
- 정규화: 데이터를 중복 없이 관리하기 위해 테이블 간 관계를 정의하고 정규화를 적용합니다.
- 트랜잭션 지원: ACID(Atomicity, Consistency, Isolation, Durability)를 준수하여 안정적인 트랜잭션 관리가 가능합니다.
- 사용 예: 금융 시스템, ERP 시스템 등 데이터의 일관성이 중요한 곳에서 주로 사용됩니다.
- 대표 DBMS: MySQL, PostgreSQL, Oracle, MS SQL Server
2. NoSQL
- 구조: 테이블 형태가 아닌, 다양한 형태(키-값, 문서, 그래프 등)의 비정형 데이터를 저장할 수 있습니다. 스키마가 유연하거나 아예 없을 수 있습니다.
- SQL 대신: SQL이 아닌 데이터 조작 방법을 사용합니다. 각 NoSQL 데이터베이스마다 고유한 쿼리 언어나 API를 사용합니다.
- 확장성: 분산형 구조를 사용하여 수평적 확장(서버를 추가하는 방식)이 용이합니다.
- 유연성: 대규모의 데이터를 빠르게 처리하며, 스키마가 없어 다양한 종류의 데이터를 유연하게 저장할 수 있습니다.
- 사용 예: 실시간 분석, 소셜 네트워크, IoT, 빅데이터 등 대규모의 비정형 데이터를 처리하는 곳에서 많이 사용됩니다.
- 대표 NoSQL DBMS: MongoDB(문서 기반), Cassandra(분산형 키-값 저장소), Redis(인메모리 키-값 저장소), Neo4j(그래프 데이터베이스)
주요 차이점
- 데이터 구조: 관계형 데이터베이스는 테이블 기반으로 엄격한 스키마가 있지만, NoSQL은 유연한 스키마로 다양한 형태의 데이터를 저장할 수 있습니다.
- 확장성: RDBMS는 수직적 확장(더 강력한 하드웨어로의 교체)이 주로 이루어지지만, NoSQL은 수평적 확장이 용이합니다.
- 트랜잭션: RDBMS는 ACID를 보장하는 트랜잭션 처리가 강력하지만, NoSQL은 성능을 우선으로 하며 일관성을 필요에 따라 희생할 수 있습니다.
따라서, NoSQL은 SQL을 사용하지 않는다는 의미가 아니라, "관계형 데이터베이스 뿐만 아니라 다양한 저장 방식도 제공한다"는 뜻입니다.
DDL(Data Definition Language, 데이터 정의 언어)
DDL(Data Definition Language, 데이터 정의 언어)은 데이터베이스의 구조를 정의하거나 수정하는 데 사용되는 SQL 명령어 집합을 말합니다. DDL은 데이터베이스의 스키마, 테이블, 인덱스 등을 생성, 수정, 삭제하는 작업을 수행합니다. DDL 명령어는 주로 데이터의 구조 자체를 정의하기 때문에, 데이터에 직접적인 영향을 주지는 않지만, 데이터베이스의 테이블 및 기타 객체들을 생성하고 관리합니다.
주요 DDL 명령어:
- CREATE: 데이터베이스 객체(테이블, 인덱스, 뷰 등)를 생성하는 명령어
- ALTER: 기존의 데이터베이스 객체를 수정하는 명령어
- DROP: 데이터베이스 객체를 삭제하는 명령어
- TRUNCATE: 테이블의 데이터를 모두 삭제하지만 테이블의 구조는 유지하는 명령어
DDL의 특징
- 자동 커밋: DDL 명령어는 실행 즉시 커밋(commit)이 발생합니다. 즉, 트랜잭션의 일부로 실행하더라도 롤백(rollback)이 불가능합니다.
- 데이터베이스 구조 변경: DDL은 데이터를 관리하기 위한 구조 자체를 정의하거나 변경하는 데 사용되므로 데이터베이스 관리의 핵심입니다.
Validate
"발리데이트(Validate)"는 특정 데이터나 값이 요구되는 조건이나 기준을 충족하는지 확인하는 과정을 의미합니다. 주로 데이터 입력이나 프로세스에서 사용자가 제공한 값이 유효한지 검사하는 데 사용됩니다.
예를 들어, 웹 애플리케이션에서 사용자가 폼을 제출할 때, 이름, 이메일, 비밀번호 등의 입력값을 받아 이를 발리데이트하는 과정을 거칩니다. 이때 발리데이트는 다음과 같은 역할을 합니다:
발리데이트의 역할:
- 유효성 검사: 값이 유효한지 검사합니다. 예를 들어, 이메일 주소 형식이 올바른지, 비밀번호가 최소 길이를 충족하는지, 숫자 값이 특정 범위 내에 있는지를 확인합니다.
- 입력 필수 항목 확인: 특정 필드가 반드시 입력되어야 하는 경우, 값이 비어 있지 않은지 확인합니다.
- 데이터 일관성 확인: 입력된 값이 시스템 내에서의 다른 값들과 일관성이 있는지 확인합니다. 예를 들어, 사용자가 중복된 사용자명을 입력하지 않았는지 확인할 수 있습니다.
- 데이터 변환: 필요에 따라 입력된 데이터를 올바른 형식으로 변환하거나 정리할 수도 있습니다. (예: 공백 제거, 소문자로 변환 등)
자주 사용되는 상황:
- 웹 폼: 로그인, 회원가입, 결제 정보 입력 등에서 사용자가 입력한 데이터의 형식이 올바른지 확인할 때.
- API 요청: 서버가 클라이언트로부터 받은 데이터가 정확하고 필요한 조건을 충족하는지 확인할 때.
- 데이터베이스 작업: 데이터베이스에 저장하기 전에 데이터의 유효성을 확인하여 오류나 충돌을 방지할 때.
비밀번호 발리데이트: 비밀번호가 8자 이상이며, 숫자와 특수 문자가 포함되어 있는지 확인합니다.
public boolean validatePassword(String password) {
return password.length() >= 8 && password.matches(".*\\d.*") && password.matches(".*[!@#$%^&*()].*");
}
요약하자면, 발리데이트는 데이터를 받아 그 값이 기대하는 형식이나 조건에 부합하는지 검사하는 과정입니다. 이를 통해 애플리케이션은 잘못된 입력이나 오류를 미리 방지할 수 있습니다.
'Study Memo' 카테고리의 다른 글
2024.09.11(수) { 지연 로딩&즉시 로딩, n+1 문제, 다이나믹 업데이트, 알아야할 것들 } (0) | 2024.09.11 |
---|---|
2024.09.10(화) { flush(), dirty, 스냅샷, 데이터베이스 정규화 } (0) | 2024.09.10 |
2024.09.06(금) { no arg = 디폴트, 마샬링 언마샬링 } (0) | 2024.09.06 |
2024.09.05(목) { 자바기반&어노테이션기반 컨피규레이션 메타데이터 차이 } (0) | 2024.09.05 |
2024.09.04(수) { 네임스페이스, 자바빈의 기본속성 } (0) | 2024.09.04 |