본 포스팅은 아래의 내용을 참조하여 작성되었습니다.

http://www.quirksmode.org/js/this.html



Javascript에서 this가 가리키는 대상이 무엇인지 정리해 보았습니다.

(라고 쓰고 Javascript에서의 Copying과 Referring에 대한 정리 라고 읽어주시면 됩니다.)


간단하게 this가 가리키는 대상을 보면 Java에서의 this와 크게 다르지 않습니다.

Java에서의 this : 현재 실행중인 메소드가 속한 클래스를 지칭

Javascript에서의 this : 현재 실행중인 함수가 속한 Owner를 지칭


하지만 Java에서 보다 Javascript에서의 this가 좀 더 변화무쌍한 녀석으로 인식되는데, 그 이유는 Java의 메소드는 클래스에 종속적 인데 비해 Javascript에서의 함수는 어느곳에나 할당될 수 있기 때문일 것입니다.


 
//func1
function doSomething(){
    this.style.color='#cc0000';
}

//func2
element.onclick = doSomething;
    
위 코드에서 func1의 경우 this는 window.doSomething 안에서의 this 이므로 window가 됩니다. 하지만 func2의 경우에는 element.onclick에 할당된 함수 안에서의 this 이므로 element가 됩니다.

Javascript에서의 함수 할당 방법으로는 Copying과 Referring이 있습니다.

Copying
함수의 복사본을 할당합니다. 위 func2의 경우가 copying에 해당합니다. func2는 다음과 같이 표현한것과 같습니다.

element.onclick = function doSometing(){
  this.style.color='#cc0000'
};
this가 element.onclick에서의 this이므로 element가 됨을 좀 더 잘 볼 수 있습니다.
아래는 모두 같은 결과를 얻는 copying 할당 방법 입니다.
element.onclick = doSomething
element.addEventListener('click', doSomething, false)
element.onclick = function() { this.style.color '#cc0000'; }
//at dom property :  onclick="this.style.color = '#cc0000';"

Referring

referring은 복사본이 할당되는 것이 아니라 함수를 참조합니다. 아래와 같이 선언한 것을 이야기합니다.

element.onclick = function (){
    doSomething(); // just say go to doSomthing..
};
이 경우 doSomething에서의 element가 아닌 func1에 의해 할당된 window가 됩니다.
아래는 모두 같은 결과를 얻는 referring 할당 방법들 입니다.
element.onclick = function() {doSomething();}
element.attachEvent('onclick', doSomething)
//at dom property : onclick="doSomething()"

Copying and Referring in Event Handling

IE 계열과 non-IE 계열의 자바스크립트 이벤트 등록을 비교해 보면 다음과 같습니다.

//W3C(non-IE)
element.addEventListener('click', doSomething, false)  //Copying
//IE
element.attachEvent('onclick', doSomething) //Referring

IE계열(Microsoft event registration model)에서 쓰이는 방식은 Referring이라서, event의 대상 html element를 알 수 없는 경우가 종종 있습니다. 이를 방지하기 위해 다음과 같이 함수 parameter로 this를 넘기는 방법을 사용하게 됩니다.

//at dom property:  onclick="doSomething(this)"
function doSomething(obj) {
    // this is present in the event handler and is sent to the function
    // obj now refers to the HTML element, so we can do
    obj.style.color = '#cc0000';
}


Posted by 제리곰
,

본 포스팅은 아래의 포스트를 참조하여 작성되었습니다.

http://amitstechblog.wordpress.com/2011/05/20/spring-transactions-behavior-on-private-and-internal-methods/



스프링 트랜잭션의 기본 모드인 proxy 모드에서는 오직 외부로부터의 method 호출이 발생한 경우에만 method가 인터셉트 되어 트랜잭션 관리가 적용된다. 즉, 다시 말해서 오브젝트 내의 한 method가 동일 오브젝트 내의 다른 method를 호출할 경우에는 피 호출 method에 @Transactional 어노테이션이 명시되어 있더라도 실행시 트랜잭션이 스프링에 의해 관리되지 않는다.


-from reference document@spring.io , 발번역


Private Method에서의 @Transactional

스프링 트랜잭션의 기본 모드에서는 private method에 @Transactional 을 붙여 봐야 스프링이 트랜잭션을 관리해 주지 않습니다. 다시 말해, @Transactional annotation 을 non-public(public visibility가 아닌 protected, private, package) method에 적용할 경우 실행시 따로 에러가 발생하지는 않지만 트랜잭션 정책이 적용되지 않습니다. 만약 이러한 non-public method에 @Transactional을 적용하려 한다면 프록시 대신 AspectJ 방식을 고려해 봐야 합니다.


Internal Method에서의 @Transactional 


public visiblilty를 가진 method지만 object 내부의 다른 method에 의한 호출로 수행되는 경우에는 private method와 마찬가지로 @Transactional 정책이 적용되지 않습니다.




결론


위 내용을 간단히 요약하면 다음과 같습니다.

  1. @Transctional은 프록시 모드로 동작한다.
  2. 그래서 외부에서 오브젝트 내의 method에 들어갈때와 나올때 적용된다. 
  3. 오브젝트 내부 호출은 적용되지 않기 때문에 Private method, Internal called Method는 @Transactional에 의한 스프링 트랜잭션 관리가 되지 않는다.


Posted by 제리곰
,


본 포스팅은 아래의 내용을 대충 한글화 하는데 초점을 맞췄다.

https://blog.codecentric.de/en/2012/03/transactions-in-spring-batch-part-1-the-basics/

본문 내 모든 이미지는 위 링크에서 참조하였다.



Spring Batch에서 생각해야 할 Transaction 개념에 대해 정리해 본다.


일반적인 어플리케이션의 경우 사용자의 액션을 기준으로 하나의 액션에 하나의 트랜잭션을 생각하면 된다. 하지만 배치 어플리케이션의 경우에는 다량의 데이터를 처리하는 배치 전체 프로세스를 트랜잭션으로 묶게 되면 데이터베이스에 무리가 될 수 있기 때문에 중간에 작업 데이터에 대한 커밋이 일어나야 한다. 만약 배치를 재실행해야 하거나 수동으로 실행해야 하는 등의 기능이 제공되어야 할 경우에는 중간에 이미 커밋된 데이터에 대해 어떻게 처리해야 할지 생각해 봐야 한다.


이하 설명은 단일 쓰레드로 이루어진 Chunk Oriented Processing에 대해 진행한다.


Chunk Oriented Steps



Chunk Oriented Processing Step은 다음과 같다.

  1. ItemReader는 item이 없을 때 까지 하나씩 item을 어딘가에서 read 한다.
  2. ItemProcessor는 item 각각에 대해 특정 process를 진행한다.
  3. ItemWriter는 item list를 받아 어딘가로 write한다.

배치 프로세스는 Chunk 단위로 구분되며 이 Chunk단위로 하나의 트랜젝션이 형성된다. exception이 발생할 경우, 해당 Chunk는 롤백이 된다. 당연히 이전에 커밋한 Chunk는 완료된 상태가 유지된다. Chunk 단위는 CompletionPolicy에 의해 결정되며 그림 속의 1번과 같이 read 단계에서 CompletionPolicy 조건이 만족될 경우 item이 남아있더라도 하나의 Chunk 단위로 묶여 다음 단계인 process 단계로 넘어가게 된다.

CompletionPolicy는 다음과 같이 설정할 수 있다.

  • commit-interval 속성을 설정할 경우, SimpleCompletionPolicy가 적용되며, 지정한 갯수의 item이 chunk단위로 묶인다.
  • CompletionPolicy에 chunk-completion-policy 속성을 지정하여 추가로 커스터마이징 할 수도 있다.

Business data and batch job data



Spring Batch는 기본적으로 몇몇 table definition을 제공한다. 이 곳에는 배치 히스토리 관리나 배치 프로세스 재시작에 이용될 수 있는 job, step, 실행 context가 저장된다. 배치 프로세스 상에서 저장되는 부분은 위 그림에 표시되어 있다. 이러한 정보를 Business data가 들어있는 DB와는 다른 별도의 DB에 저장할 수 있지만, JtaTransactionManager, DataSources등을 따로 지정해줘야 하고, 각각의 DB에 연결해야 하는 성능상 이슈 등이 발생할 수 있으므로 보통 추천하지는 않는다.


A Failted Batch

배치가 실패했을 경우를 좀 더 자세히 살펴보면 다음과 같다.



Chunk 단위 내에서 exception이 발생할 경우 rollback이 발생하고 해당 step 및 해당 batch job은 fail상태로 기록된다. job data 기록부분은 별도의 transaction으로 묶여있기 때문에 기록이 가능하다. 만약 특정 exception의 경우 무시하고 진행하길 원할 경우 아래처럼 no-rollback-exception-class에 해당 exception을 등록해 주면 된다.


<batch:tasklet>
  <batch:chunk ... />
  <batch:no-rollback-exception-classes>
    <batch:include class="some.ignoreable.MyRuntimeException"/>
  </batch:no-rollback-exception-classes>
</batch:tasklet>


Transaction Attributes

각 transaction에 대해 지정할 수 있는 속성은 다음과 같다.

  • Propagation Type ( 기본 : REQUIRED)
  • Isolation Level ( 기본 : DEFAULT)
  • Timeout
<batch:tasklet>
  <batch:transaction-attributes isolation="READ_COMMITTED" propagation="REQUIRES_NEW" timeout="200"/>
  <batch:chunk reader="myItemReader" writer="myItemWriter" commit-interval="20"/>
</batch:tasklet>


Posted by 제리곰
,