분산 트랜잭션의 특징은, "한 쪽이 실패하면 나머지 참여 트랜잭션들 또한 실패처리 되어야 한다"는 점이다. 그렇지 않으면 데이터의 일관성과 원자성을 보장할 수 없다.

불고기버거와 치킨버거의 빵 부분은 비슷한 것과 같은 이치다.

이런 분리를 AOP 관점의 프로그래밍이라고 할 수 있다.

ex) 계좌 '조회' 트랜잭션과, 계좌 '이체' 트랜잭션은 서로 독립적이다. 즉 "두 트랜잭션은 서로 분리 트랜잭션이다,

"통제(락) 없인, 그 어떤 방법으로도 동시접근을 효율적으로 컨트롤 할 수 없기 때문이다" 라던데 상황에 따라 예외는 존재한다(ex: read만 하는 동시접근일경우 락이 필요할까?).

싱글톤 패턴 구현 방법은 크게 두 가지로 나뉘는데, 1. 메모리가 올라올 때 생성하는 방법 2. 객체가 호출될 때 생성하는 방법

Bean = 객체 Bean Container = 객체들의 풀(pool)

살아 있는 상태의 코드?? 같은거 라더라

이 jar 파일은 여러 파일을 "하나의 파일" 변환한 것이기에 관리가 편하다는 장점이 있다.

조금 특별한 변수다. 변수의 표준화가 목적 중 하나인 것 같다.

여기저기 기업들이 자주 쓰는 그런 기술인가보다...

각 방향으로의 통신을 의미한다.

하나의 Thread안에 여러개의 Transaction이 존재할 수 있다.

AP서버는 쉽게 말하면, 그냥 우리가 아는 일반적인 서버다.

기업 + 우리들 + 시간 + 노력 + J2EE = 기업에서 우리들이 월급을 받기 위해 자바로 만든 프로그램

위 예시처럼 삭제될 구 클래스는 이름에 글자 하나(여기선 hello의 'l')을 빼서 뉴 클래스가 컴파일 되는데 문제 없게 한다.

오버라이딩은 재정의, 오버로딩은 확장.

이게 있으면 xml을 몰라도 java로 xml을 쓸 수 있다. 반대도 가능.

그 공유된 장소에 다수의 개발자가 코드를 동시에 관리하며, 이는 곧 버전관리가 된다는 말이다. git이 대표적인 예시다.

구현에서 막히면... 그냥 놀고 먹어서 그런거다.