jaeiktech

빈 팩토리를 확장한 IOC 컨테이너 빈의 등록 관리등은 빈팩토리와 동일 스프링이 제공하는 각종 부가 서비스 추가 제공 싱글톤을 저장하고 관리하는 싱글톤 레지스트리이기도함 애플리케이션 컨텍스트는 IOC방식을 따라 만들어진 일종의 빈 팩토리 애플리케이션 컨택스트와 빈 팩토리는 동일하다고 생각하면 됨 빈 팩토리는 빈을 생성하고 관계르 설정하는 ioc의 기본 기능에 초점을 맞춘것이고 애플리케이션 컨택스트는 애플리캐이션 전반에 걸쳐 모든 구성요소의 제어 작업을 담당하는 IOC 엔진이라는 의미 설정정보 애플리케이션 콘택스트 또는 빈 팩토리가 IOC를 적용하기 위해 사용하ㅡㄴ 매타정보

스프링의 IOC를 담당하는 핵심 컨텡이너 빈을 등록 생성 조회 반환 관리 담당 빈 팩토리를 좀 더 확장한 애플리케이션 컨태스트를 주로 사용함

스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트를 빈이라 함 스프링 빈은 스프링 컨테이너가 생성과 관계설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트임

오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지 않음 생성하지도 않음 어떻게 만들어지고 어디서 사용되느니 아루없음 모든 제어 권한을 다른 대상에게 위임 모든 오브텍트는 위임받은 제어 권한을 갖는 특별한 오브젝트에 의해 만들어짐

토비스프링 공부 중에 배움 어떠한 일들이 순서대로 시행되고 일을 순서대로 유지해야하는데일부의 일이 단계가 다를때클래스를 추상클래스로 만들고 일부의 일만 추상메서드로 만들어서 하위 클래스에서 구현한다. public abstract class DataProcessor { // 템플릿 메서드 public final void process() { loadData(); processData(); saveData(); } protected void loadData() { System.out.println("데이터 로딩"); } // 변하는 부분 protected abstract void processData(); prote..

데드락이 발생할수있는 조건 4가지 4가지 조건을 다 채워야 발생한다.1. 상호배제 (Mutual exclusion) : 자원은 한 프로세스만 사용해야한다.2. 점유대기 (Hold and wait) : 하나의 자원을 점유하고 있으면서 다른 프로세스에 할당되어 사용중인 자원을 추가로 점유하기 위해 대기하는 프로세스가 있어야한다.3. 비선점 (No preemption) : 다른 프로세스에 할당된 자원을 강제로 빼앗을 수 없다4. 순환 대기 (Circluar wait) : 한 프로세스는 다음 프로세스가 점유한 자원을 대기하고 다음 프로세스는 그 다음 프로세스가 점유한 자원을 대기하고 그 다음 프로세스는 처음 프로세스가 점유한 자원을 대기해야한다. 참고로 레이스 컨디션과 데드락은 다름레이스 컨디션은 타이밍문제데드..

메모리는1. 코드 영역 - 실행할 프로그램의 코드2. 데이터 영역 - 전역 변수, 정적 변수3. 힙 영역 - 동적 할당4. 스택 영역 - 지역 변수, 매개 변수으로 구분됨 힙 영역은 런타임에 크기가 결정됨스택 영역은 컴파일 타임에 크기가 결정됨

Target Object : 부가기능을 부여할 대상 Aspect가 적용될 실제 비즈니스 객체이며 프로시의 대상 프록시로 감싸지기 전의 원본 객체Aspect(스프링에서는 advisor) : 공통 관심사를 모듈화한 단위 advice와 pointcut을 함께 정의Advice : 적용할 부가기능과 언제 실행되는지를 정의Join point : Advice를 적용할 수 있는 후보 지점pointcut : Join point에서 Advice를 적용할 지점을 선별하는 조건 런타임시 위빙 (애플리케이션 콘텍스트를 만들 때)빈으로 등록된 타겟만 AOP 적용 가능빈으로 만들때 빈 후처리기에서 어드바이저 조회빈에서 pointcut에 매칭되는 메서드가 있는지 확인빈을 원본빈이 아닌 프록시로 삽입 @트랜잭셔널은 AOP 활용내부호출..

요약1. 최초에 히카리데이터소스에서 풀엔트리크리에이터 생성 풀 엔트리크리에이터에서 콜() 호출2. 히카리풀에서 createPoolEntry() 호출 PollBase에서 newPollEntry() 호출 뉴커넥션 호출 히카리데이터소스에서 겟커넥션 호출 커넥션 반환3. 커넥션을 복사해서 커넥션풀 만큼 커넥션을 만듬4. @Tramsctional 달린 메소드 시작 트랜잭션인터셉터 호출5. TransactionAspectSupport의 invokeWithinTransaction() 호출 createTransactionIfNecessary() 호출 6. 플랫폼트랜잭션매니저의 구현체인 AbstractPlatformTransactionManager에서 겟트랜잭션시작7. AbstractPlatformTransactionM..

게시판의 제목, 제목+내용 검색에는 FULLTEXT 인덱스를 적용했지만, 작성자 검색에는 적용하지 않았습니다. FULLTEXT에는 불용어 개념이 있습니다. 한마디로 텍스트를 언어의 개념으로 간주하여 의미가 있는 제목, 내용에는 적합하나 주로 의미 없는 문자열로 구성된 작성자 검색에는 부적합하다 생각했습니다. 문제 진단 및 원인 분석따라서 유니크 인덱스를 이용하여 작성자 검색을 하게 되는데 %LIKE% 검색 시 유니크 인덱스를 사용할 수 없다는 문제가 있었습니다. 이로 인해 인덱스를 포기하고 %LIKE%로 정확성을 확보할 것인지, 혹은 인덱스를 활용하여 속도를 확보할 것인지 고민했습니다.다음과 같은 분석을 통해 해결책을 모색했습니다.짧은 검색어일수록 중간 단어 검색(%LIKE%)을 선호하는 경향이 있습니다..