기록들 https://github.com/ndgndg91

이번글에서는 JDBC API Statement 와 PreparedStatement 의 차이점에 대해서 정리하려고한다. Java Database Connectivity API 는 Java 를 사용하여 data access 를 할 수 있도록 제공해준다. RDBMS 뿐만 아니라 spreadsheets 와 flat files 도 가능하다. JDBC API 는 2개의 패키지로 구성된다. - java.sql - javax.sql Statement String-based query 를 실행시킨다. parameter 대신 static SQL 을 처리하기 좋다. runtime 에 오직 한 번만 실행시킬 DDL 을 사용하기 적합하다. Binary Data Read / Write 작업에 사용이 불가능하다. Binary Protocol 이 사용되지 않는다. SQL Injection 에 취약하다. PreparedStatement parameterized query 를 기반으로 한다. runtime 에 parameter 를 다루고 여러번 수행되는 어떤 종류의 Query 도 처리하기 좋다. Dynamic query 를 처리하기 좋다. Binary Data Read / Write 작업이 가능하다. Binary Protocol 사용이 가능하다. 둘의 가장 큰 차이점은 precompiled 에 따른 성능과 보안 측면에서 SQL injection 방지이다. 참조 https://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/ https://www.baeldung.com/java-statement-preparedstatement https://www.geeksforgeeks.org/difference-between-statement-and-preparedstatement/ https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html#:~:text=As%20a%20result%2C%20the%20...

개요  Spring Framework 를 사용할 때 AOP 는 필수라고 말해도 과언이 아니다. Logging, Transaction Management, Caching, Security 등등 에서 주로 사용된다. 그렇다면 Spring AOP 는 어떻게 동작할까? 이번 글에서 정리를 해보려고 한다.  Spring 에서 AOP 는 JDK Dynamic Proxy 혹은 CGLIB Dynamic Proxy 를 사용하여 Proxy 를 생성하여 관리한다.  Proxy target object 가 하나 이상의 interface 를 구현하는 경우에는 JDK Dynamic Proxy 가 사용된다. 반대로 target object 가 interface 를 구현하지 않는다면 CGLIB proxy 가 생성된다. 하지만 proxy-target-class=true 로 설정한다면 interface 를 구현하더라도 CGLIB proxy 가 사용된다. CGLIB Proxy 를 사용할 때 고려해야 할 몇가지가 있다. - final method 는 overriding 이 불가능하기 때문에 advice 적용이 불가능하다.  - target class 가 final 일 경우 불가능하다. - Spring 3.2 version 전의 경우 CGLIB 와 관련된 jar 를 classpath 에 추가해주어야 한다. 3.2 version 부터는 org.springframework.cglib 로 repackaged 되어 spring-core jar 안에 포함이 되었다. - Spring 4.0 version 전의 경우 proxy target object 의 생성자는 두 번 호출되었다. 또한 기본 생성자가 필수였다. 4.0 version 이후부터는 Objenesis 를 통해서 proxy instance 가 생성될 때 더이상 생성자가 두 번 호출되지 않게 되었다. 일반적이지 않은 경우이지만 4.0 version 전에서는 proxy target object 의 생성자에 주요한 로직을...

이번 글에서는 System Call 과 I/O 에 대한 기본적인 개념을 정리하려고 한다. System Call? 프로그램이 실행되는 OS 의 커널에게 요청하는 프로그래밍 방식이라고 정의할 수 있다. 하드 디스크 드라이브 또는 카메라 등 하드웨어와 관련된 요청일 수 도 있고, 새로운 프로세스를 생성하거나 실행에 대한 요청일 수 도 있고, 프로세스 스케쥴링과 같은 요청일 수 있다. 즉, 프로세스가 해당 OS 의 커널 서비스를 사용하는 것을 시스템 콜이라고 한다. System call 의 종류는 어떤것이 있을까? 크게 6가지로 정리할 수 있다. 1. Process Control     - create process     - terminate process     - load, execute     - get/set process attributes     - wait for time, wait event, signal event     - allocate and free memory     Java 를 기준으로 간단한  예시를 작성해보았다. ProcessBuilder 를 통해서 ls shell command 를 새로운 process 를 생성하여 실행하고 main process id 와 새로 생성한 process id 를 출력하고 process 를 종료하는 코드이다. 이과정에서        이외에도 현재 살아있는 모든 process 에 대한 정보를 비동기로 가져와서 출력한다. 2. File management     - create file, delete file     - open, close     - read, write, reposition     - get/set file attributes Java 통해서 간...

 Race Condition 즉 동시성 문제는 하나의 트랜잭션이 다른 트랜잭션에서 동시에 변경한 데이터를 읽거나 두 트랜잭션이 동시에 같은 데이터를 변경하고자 할 때 나타난다. 동시성 문제로 발생하는 버그는 타이밍에 운이 없을 때 발생하기 때문에 일반적인 테스트로 발견하기 어렵고, 타이밍 이슈는 간할적으로 발생할 수 있으며 해당 이슈를 재현하기 힘들고 추론도 힘들다. 어플리케이션 개발은 한 번에 한 사용자를 가정하고 개발하기도 어려운데 동시 사용자가 많다면 당연히 더 어렵다. 하지만 현실세계에서 동시성이 없는 어플리케이션이 없다고 봐도 무방할 만큼 동시성을 고려하지 않을 수 없다. 재고가 얼마 남지 않은 상품을 동시에 여러 구매자가 구매할 때, 하나의 회의실을 서로가 먼저 예약하려고 할 때, BTS 콘서트 티켓을 예매할 때.. 등등 Optimistic Concurrency Control 우리나라말로 해석하면 "낙관적 동시성 제어" 이다. 무엇이 낙관적일까? 위험한 상황이 발생할 가능성이 있을 때 Transaction 을 막는 대신 모든것이 괜찮아질 것이라고 희망을 갖고 계속 진행한다는 의미이다. 여기서 위험한 상황이란 다른 Transaction 이 현재 진행 중인 Transaction 이 변경하려고 하는 데이터와 동일한 데이터를 변경하고자 하는 상황을 의미한다. 그리고 막는다는 표현은 Database 관점에서 Exclusive Lock 을 통해서 Transaction 이 순서로 진행되는 것을 의미한다. 막지 않는 대신 각각의 Transaction 은 Commit 전에 Transaction 내에서 읽었던 Data 가 변경되지 않은것을 확인한다. 이는 이른바 MVCC(Multi Version Concurrency Control) 기법을 통해서 이루어진다. 만약 Data 의 변경이 감지된다면 해당 Transaction 은 Rollback 하고 재시작을 한다. Pessimistic Concurrency Control 낙관적의 반대인 비관적이라는 말은...