diff --git a/src/site/ko/markdown/README.md b/src/site/ko/markdown/README.md
index 4e31a121bc..03cf1d3fa2 100644
--- a/src/site/ko/markdown/README.md
+++ b/src/site/ko/markdown/README.md
@@ -1,6 +1,6 @@
# 목차
-이 페이지는 GitHub에서 인덱스를 렌더링하기위한 것입니다.
+이 페이지는 GitHub에서 인덱스를 렌더링하기 위한 것입니다.
> **NOTE:**
>
diff --git a/src/site/ko/markdown/batch.md b/src/site/ko/markdown/batch.md
index 87b11c2600..cdcd9d0b5b 100644
--- a/src/site/ko/markdown/batch.md
+++ b/src/site/ko/markdown/batch.md
@@ -1,15 +1,15 @@
# Spring Batch
-마이바티스 스프링 연동모듈의 1.1.0버전에서는 스프링 배치 애플리케이션을 만들기 위해 세개의 빈을 제공한다.
-세개의 빈은 `MyBatisPagingItemReader` 와 `MyBatisCursorItemReader` 와 MyBatisBatchItemWriter
이다.
+마이바티스 스프링 연동 모듈의 1.1.0버전에서는 스프링 배치 애플리케이션을 만들기 위해 세 개의 빈을 제공한다.
+세 개의 빈은 `MyBatisPagingItemReader` 와 `MyBatisCursorItemReader` 와 MyBatisBatchItemWriter
이다.
또한 2.0.0 버전에서는 Java Configuration 을 지원하는 다음의 세 가지 Builder class 를 제공한다.
`MyBatisPagingItemReaderBuilder`, `MyBatisCursorItemReaderBuilder` 그리고 `MyBatisBatchItemWriterBuilder` 이다.
중요
이 문서는 [스프링 배치](http://static.springsource.org/spring-batch/) 에 대한 것으로 마이바티스 배치 `SqlSession` 을 다루지는 않는다.
-배치 세션에 대해서는 [SqlSession 사용](sqlsession.html) 에서 좀더 다루었다.
+배치 세션에 대해서는 [SqlSession 사용](sqlsession.html) 에서 좀 더 다루었다.
# MyBatisPagingItemReader
@@ -17,15 +17,15 @@
요청된 데이터를 가져오기 위해 `setQueryId` 프로퍼티에 명시된 쿼리를 실행한다.
쿼리는 `setPageSize` 프로퍼티에 명시된 크기만큼 데이터를 가져오도록 실행된다.
-`read()` 메서드를 사용하면 필요할 때 현재 위치에서 정해진 수 만큼 더 추가 데이터를 가져온다.
-reader는 몇가지의 표준적인 쿼리 파라미터를 제공하고 명명된 쿼리의 SQL은 요청된 크기만큼의 데이터를 만들기 위해 파라미터의 일부 혹은 모두 사용한다.
-여기서 사용가능한 파라미터이다.
+`read()` 메서드를 사용하면 필요할 때 현재 위치에서 정해진 수만큼 더 추가 데이터를 가져온다.
+reader는 몇 가지의 표준적인 쿼리 파라미터를 제공하고 명명된 쿼리의 SQL은 요청된 크기만큼의 데이터를 만들기 위해 파라미터의 일부 혹은 모두 사용한다.
+여기서 사용 가능한 파라미터이다.
* `_page`: 읽을 페이지 수(0부터 시작)
* `_pagesize`: 페이지의 크기, 이를테면 리턴하는 로우 수
* `_skiprows`: `_page` 와 `_pagesize`를 곱한 결과
-각각의 파라미터는 selet구문에서 다음처럼 매핑될 수 있다.
+각각의 파라미터는 selet구문에서 다음처럼 매핑 될 수 있다.
```xml
@@ -55,7 +55,7 @@ public class BatchAppConfig {
}
```
-**좀더 복잡한 예제를 보자.**
+**좀 더 복잡한 예제를 보자.**
```xml
@@ -246,16 +246,16 @@ public class BatchAppConfig {
```
-**여러개의 테이블에 데이터를 쓰려면 한꺼번에 처리할 수 있도록 만든 writer(몇가지 규칙을 가지고)를 사용하자.**
+**여러 개의 테이블에 데이터를 쓰려면 한꺼번에 처리할 수 있도록 만든 writer(몇 가지 규칙을 가지고)를 사용하자.**
이 기능은 마이바티스 3.2이상에서만 사용할 수 있다. 이전의 버전에서는 예상과 다르게 동작하는데 그 내용은 [이슈](http://code.google.com/p/mybatis/issues/detail?id=741)를 참고하면 된다.
-배치가 관계를 가지는 데이터나 여러개의 데이터베이스를 다루는 것처럼 복잡한 데이터를 작성할때 필요하다면 insert구문이 한개에 테이블에만 데이터를 넣을수 있다는 사실만 피하면 가능하기도 하다.
+배치가 관계를 가지는 데이터나 여러 개의 데이터베이스를 다루는 것처럼 복잡한 데이터를 작성할 때 필요하다면 insert구문이 한 개에 테이블에만 데이터를 넣을 수 있다는 사실만 피하면 가능하기도 하다.
이런 복잡한 데이터를 처리하기 위해 writer가 작성하는 아이템(Item) 을 준비해야 한다. 다음의 기술을 사용하면 단순한 관계를 가진 데이터나 관계가 없는 테이블을 처리하는 아이템에서 사용할 수 있다.
-이러한 방법으로 스프링 배치 아이템은 모든 레코드를 *다룰것이다*.
-여기에는 1:1 *관계*를 가지는 *InteractionMetadata*, 관계가 없는 두개의 로우는 *VisitorInteraction* 와 *CustomerInteraction*이 있다.
-이 각각의 객체는 다음과 같이 볼수 있다.
+이러한 방법으로 스프링 배치 아이템은 모든 레코드를 *다룰 것이다*.
+여기에는 1:1 *관계*를 가지는 *InteractionMetadata*, 관계가 없는 두 개의 로우는 *VisitorInteraction* 와 *CustomerInteraction*이 있다.
+이 각각의 객체는 다음과 같이 볼 수 있다.
```java
public class InteractionRecordToWriteInMultipleTables {
@@ -271,7 +271,7 @@ public class Interaction {
}
```
-그리고 스프링 설정에는 각각의 레코드를 처리하기위해 특별히 설정된 전용(delegates) writer를 사용하는 `CompositeItemWriter`가 있다.
+그리고 스프링 설정에는 각각의 레코드를 처리하기 위해 특별히 설정된 전용(delegates) writer를 사용하는 `CompositeItemWriter`가 있다.
```xml
@@ -304,7 +304,7 @@ public class BatchAppConfig {
}
```
-각각의 전용(delegate) writer는 필요할 만큼 설정할 수 있다. 예를들면 *Interaction* 과 *InteractionMetadata*를 위한 writer가 있다.
+각각의 전용(delegate) writer는 필요할 만큼 설정할 수 있다. 예를 들면 *Interaction* 과 *InteractionMetadata*를 위한 writer가 있다.
```xml
```
-reader와 동일하게 `statementId`는 네임스페이스를 가진 구문을 가리킬수 있다.
+reader와 동일하게 `statementId`는 네임스페이스를 가진 구문을 가리킬 수 있다.
매퍼 파일에서 구문은 다음과 같은 방법으로 각각의 레코드를 위해 만들어져있다.
@@ -345,9 +345,9 @@ reader와 동일하게 `statementId`는 네임스페이스를 가진 구문을
```
-먼저 `insertInteractionMetadata`가 호출될것이고 update구문은 jdbc드라이버에 의해(`keyProperty` 와 `keyColumn`) 생성된 아이디들을 리턴하기 위해 설정되었다.
-`InteractionMetadata` 객체가 이 쿼리에 의해 업데이트되면 다음의 쿼리는 `insertInteraction`를 통해 상위객체인 `Interaction`를 작성하기 위해 사용될수 있다.
+먼저 `insertInteractionMetadata`가 호출될 것이고 update구문은 jdbc드라이버에 의해(`keyProperty` 와 `keyColumn`) 생성된 아이디들을 리턴하기 위해 설정되었다.
+`InteractionMetadata` 객체가 이 쿼리에 의해 업데이트되면 다음의 쿼리는 `insertInteraction`를 통해 상위객체인 `Interaction`를 작성하기 위해 사용될 수 있다.
-***방금 언급한 내용에 관련하여 JDBC드라이버가 똑같이 동작하지 않을수 있다.
+***방금 언급한 내용에 관련하여 JDBC드라이버가 똑같이 동작하지 않을 수 있다.
이 글을 쓰는 시점에 H2 드라이버 1.3.168버전(`org.h2.jdbc.JdbcStatement#getGeneratedKeys`를 보라)만 배치모드에서 마지막 인덱스를 리턴한다.
반면에 MySQL 드라이버는 기대한 것과 동일하게 동작하고 모든 아이디를 리턴한다.***
diff --git a/src/site/ko/markdown/factorybean.md b/src/site/ko/markdown/factorybean.md
index e0a79081ad..4c8cff57b4 100644
--- a/src/site/ko/markdown/factorybean.md
+++ b/src/site/ko/markdown/factorybean.md
@@ -2,11 +2,11 @@
# SqlSessionFactoryBean
마이바티스만 사용하면, `SqlSessionFactory`는 `SqlSessionFactoryBuilder`를 사용해서 생성한다.
-마이바티스 스프링 연동모듈에서는, `SqlSessionFactoryBean`가 대신 사용된다.
+마이바티스 스프링 연동 모듈에서는, `SqlSessionFactoryBean`가 대신 사용된다.
## 설정
-팩토리 빈을 생성하기 위해, 스프링 XML설정파일에 다음설정을 추가하자.
+팩토리 빈을 생성하기 위해, 스프링 XML 설정 파일에 다음 설정을 추가하자.
```xml
@@ -31,23 +31,23 @@ public class MyBatisConfig {
```
일반적인 마이바티스 스프링 사용법에서는, `SqlSessionFactoryBean`이나 관련된 `SqlSessionFactory`를 직접 사용할 필요가 없다.
-대신 세션 팩토리가 `MapperFactoryBean`나 `SqlSessionDaoSupport`를 확장하는 다른 DAO에 주입될것이다.
+대신 세션 팩토리가 `MapperFactoryBean`나 `SqlSessionDaoSupport`를 확장하는 다른 DAO에 주입될 것이다.
## 속성
`SqlSessionFactory`는 JDBC `DataSource`의 필수 프로퍼티가 필요하다. 어떤 `DataSource`라도 상관없고 다른 스프링 데이터베이스 연결처럼 설정되어야만 한다.
-하나의 공통적인 프로퍼티는 마이바티스 XML설정파일의 위치를 지정하기 위해 사용되는 `configLocation`이다. 이 프로퍼티를 설정하는 것은 디폴트 설정을 가진 마이바티스 설정을 변경해야 할 경우 뿐이다.
+하나의 공통적인 프로퍼티는 마이바티스 XML 설정 파일의 위치를 지정하기 위해 사용되는 `configLocation`이다. 이 프로퍼티를 설정하는 것은 디폴트 설정을 가진 마이바티스 설정을 변경해야 할 경우 뿐이다.
대개는 ``과 `` 섹션을 변경하는 경우이다.
-설정파일이 마이바티스 설정을 완전히 다룰 필요는 없다. 어떤 환경, 어떤 데이터소스 그리고 마이바티스 트랜잭션 관리자가 **무시**될수도 있다.
+설정 파일이 마이바티스 설정을 완전히 다룰 필요는 없다. 어떤 환경, 어떤 데이터소스 그리고 마이바티스 트랜잭션 관리자가 **무시**될 수도 있다.
`SqlSessionFactoryBean` 는 필요에 따라 이 값들을 설정하여 자체적인 MyBatis `Environment` 를 만든다.
-설정파일이 필요한 다른 이유는 마이바티스 XML파일이 매퍼 클래스와 동일한 클래스패스에 있지 않은 경우이다. 이 설정을 사용하면 두가지 옵션이 있다.
-첫번째는 마이바티스 설정파일에 `` 섹션을 사용해서 XML파일의 클래스패스를 지정하는 것이다. 두번째는 팩토리 빈의 `mapperLocations` 프로퍼티를 사용하는 것이다.
+설정 파일이 필요한 다른 이유는 마이바티스 XML파일이 매퍼 클래스와 동일한 클래스패스에 있지 않은 경우이다. 이 설정을 사용하면 두 가지 옵션이 있다.
+첫 번째는 마이바티스 설정파일에 `` 섹션을 사용해서 XML파일의 클래스패스를 지정하는 것이다. 두 번째는 팩토리 빈의 `mapperLocations` 프로퍼티를 사용하는 것이다.
`mapperLocations` 프로퍼티는 매퍼에 관련된 자원의 위치를 나열한다. 이 프로퍼티는 마이바티스의 XML매퍼 파일들의 위치를 지정하기 위해 사용될 수 있다.
-디렉터리 아래 모든 파일을 로드하기 위해 앤트(Ant) 스타일의 패턴을 사용할수도 있고 가장 상위 위치를 지정하는 것으로 재귀적으로 하위 경로를 찾도록 할수도 있다. 예를 들어보면 다음과 같다.
+디렉터리 아래 모든 파일을 로드하기 위해 앤트(Ant) 스타일의 패턴을 사용할 수도 있고 가장 상위 위치를 지정하는 것으로 재귀적으로 하위 경로를 찾도록 할 수도 있다. 예를 들어보면 다음과 같다.
```xml
@@ -58,7 +58,7 @@ public class MyBatisConfig {
이 설정은 `sample.config.mappers` 패키지 아래와 그 하위 패키지를 모두 검색해서 마이바티스 매퍼 XML파일을 모두 로드할 것이다.
-컨테이너 관리 트랜잭션을 사용하는 환경에서 필요한 하나의 프로퍼티는 `transactionFactoryClass` 이다. 이에 관련해서는 트랜잭션을 다루는 장에서 볼수 있다.
+컨테이너 관리 트랜잭션을 사용하는 환경에서 필요한 하나의 프로퍼티는 `transactionFactoryClass` 이다. 이에 관련해서는 트랜잭션을 다루는 장에서 볼 수 있다.
만약 multi-db 기능을 사용한다면 다음과 같이 `databaseIdProvider` 속성을 설정해야 한다.
@@ -83,7 +83,7 @@ public class MyBatisConfig {
````
NOTE
-1.3.0 버전 부터 `configuration` 속성이 추가되었다. 다음과 같이 MyBatis XML 설정 파일없이 `Configuration` 인스턴스를 직접 지정할 수 있습니다.
+1.3.0 버전부터 `configuration` 속성이 추가되었다. 다음과 같이 MyBatis XML 설정 파일 없이 `Configuration` 인스턴스를 직접 지정할 수 있습니다.
```xml
diff --git a/src/site/ko/markdown/getting-started.md b/src/site/ko/markdown/getting-started.md
index 9547c6f39a..553dda2ba5 100644
--- a/src/site/ko/markdown/getting-started.md
+++ b/src/site/ko/markdown/getting-started.md
@@ -1,11 +1,11 @@
# 시작하기
-이 장은 마이바티스 스프링 연동모듈을 설치하고 셋팅하는 방법에 대해 간단히 보여준다. 그리고 트랜잭션을 사용하는 간단한 애플리케이션을 만드는 방법까지 다룰 것이다.
+이 장은 마이바티스 스프링 연동 모듈을 설치하고 셋팅하는 방법에 대해 간단히 보여준다. 그리고 트랜잭션을 사용하는 간단한 애플리케이션을 만드는 방법까지 다룰 것이다.
## 설치
-마이바티스 스프링 연동모듈을 사용하기 위해서, 클래스패스에 `mybatis-spring-${project.version}.jar`를 포함시켜야 한다.
+마이바티스 스프링 연동 모듈을 사용하기 위해서, 클래스패스에 `mybatis-spring-${project.version}.jar`를 포함시켜야 한다.
메이븐을 사용하고 있다면 pom.xml에 다음처럼 의존성을 추가하면 된다.
@@ -19,10 +19,10 @@
## 빠른 설정
-마이바티스를 스프링과 함께 사용하려면 스프링의 애플리케이션 컨텍스트에 적어도 두개를 정의해줄 필요가 있다.
-두가지는 `SqlSessionFactory`와 한개 이상의 매퍼 인터페이스이다.
+마이바티스를 스프링과 함께 사용하려면 스프링의 애플리케이션 컨텍스트에 적어도 두 개를 정의해 줄 필요가 있다.
+두 가지는 `SqlSessionFactory`와 한 개 이상의 매퍼 인터페이스이다.
-마이바티스 스프링 연동모듈에서, `SqlSessionFactoryBean`은 `SqlSessionFactory`를 만들기 위해 사용된다. 팩토리 빈을 설정하기 위해, 스프링 설정파일에 다음 설정을 추가하자.
+마이바티스 스프링 연동 모듈에서, `SqlSessionFactoryBean`은 `SqlSessionFactory`를 만들기 위해 사용된다. 팩토리 빈을 설정하기 위해, 스프링 설정 파일에 다음 설정을 추가하자.
```xml
@@ -62,10 +62,10 @@ UserMapper인터페이스는 다음처럼 `MapperFactoryBean`을 사용해서
```
-매퍼는 **반드시** 구현체 클래스가 아닌 인터페이스로 정의되어야 한다. 예를들어, 애노테이션이 SQL을 명시하기 위해 사용되지만 마이바티스 매퍼 XML파일 또한 사용될 수 있다.
+매퍼는 **반드시** 구현체 클래스가 아닌 인터페이스로 정의되어야 한다. 예를 들어, 애노테이션이 SQL을 명시하기 위해 사용되지만 마이바티스 매퍼 XML파일 또한 사용될 수 있다.
-한번만 설정하면, 다른 스프링 빈에 주입하는 같은 방법으로 비즈니스/서비스 객체에 매퍼를 직접 주입할 수 있다. `MapperFactoryBean`은 `SqlSession`을 생성하고 닫는 작업을 잘 다룬다.
-실행중인 스프링 트랜잭션이 있다면, 트랜잭션이 완료되는 시점에 커밋이나 롤백이 될 것이다. 마지막으로 예외가 발생하면 스프링의 `DataAccessException`예외가 발생한다.
+한 번만 설정하면, 다른 스프링 빈에 주입하는 같은 방법으로 비즈니스/서비스 객체에 매퍼를 직접 주입할 수 있다. `MapperFactoryBean`은 `SqlSession`을 생성하고 닫는 작업을 잘 다룬다.
+실행 중인 스프링 트랜잭션이 있다면, 트랜잭션이 완료되는 시점에 커밋이나 롤백이 될 것이다. 마지막으로 예외가 발생하면 스프링의 `DataAccessException`예외가 발생한다.
자바로 설정하면 다음과 같다.
diff --git a/src/site/ko/markdown/index.md b/src/site/ko/markdown/index.md
index e2bd35161f..a43f6578aa 100644
--- a/src/site/ko/markdown/index.md
+++ b/src/site/ko/markdown/index.md
@@ -3,18 +3,18 @@
## MyBatis-Spring 은 무엇일까?
-마이바티스 스프링 연동모듈은 마이바티스와 스프링을 편하고 간단하게 연동한다. 이 모듈은 마이바티스로 하여금 스프링 트랜잭션에 쉽게 연동되도록 처리한다. 게다가 마이바티스 매퍼와 `SqlSession`을 다루고 다른 빈에 주입시켜준다.
-마이바티스 예외를 스프링의 `DataAccessException`로 변환하기도 하고 마이바티스, 스프링 또는 마이바티스 스프링 연동모듈에 의존성을 없애기도 한다.
+마이바티스 스프링 연동 모듈은 마이바티스와 스프링을 편하고 간단하게 연동한다. 이 모듈은 마이바티스로 하여금 스프링 트랜잭션에 쉽게 연동되도록 처리한다. 게다가 마이바티스 매퍼와 `SqlSession`을 다루고 다른 빈에 주입시켜준다.
+마이바티스 예외를 스프링의 `DataAccessException`로 변환하기도 하고 마이바티스, 스프링 또는 마이바티스 스프링 연동 모듈에 의존성을 없애기도 한다.
## 동기 부여
-스프링 2.x은 아이바티스 2.x만을 지원한다. 스프링 3.x에서 마이바티스 3.x를 지원하기 위한 시도가 진행중이다. (스프링의 이슈관리 시스템인 [이슈](https://jira.springsource.org/browse/SPR-5991) 를 보라.)
-불행하게도 스프링 3의 개발이 마이바티스 3.0의 정식릴리즈전에 개발이 완료되었다. 그래서 스프링팀은 릴리즈가 안된 마이바티스 코드를 함께 릴리즈하는 것을 원하지 않았고 실제적인 스프링 지원을 기다릴수밖에 없었다.
+스프링 2.x은 아이바티스 2.x만을 지원한다. 스프링 3.x에서 마이바티스 3.x를 지원하기 위한 시도가 진행 중이다. (스프링의 이슈관리 시스템인 [이슈](https://jira.springsource.org/browse/SPR-5991) 를 보라.)
+불행하게도 스프링 3의 개발이 마이바티스 3.0의 정식 릴리즈 전에 개발이 완료되었다. 그래서 스프링팀은 릴리즈가 안 된 마이바티스 코드를 함께 릴리즈하는 것을 원하지 않았고 실제적인 스프링 지원을 기다릴 수밖에 없었다.
스프링의 마이바티스 지원에 대한 관심으로 인해, 마이바티스 커뮤니티는 재결합하는 형태로 결정을 내고 대신 마이바티스의 하위 프로젝트 형태로 스프링 연동 프로젝트를 추가한다.
## 필요 조건
-마이바티스 스프링 연동을 시작하기 전에, 마이바티스와 스프링의 용어를 맞추는 일이 굉장히 중요했다. 이 문서는 배경지식이나 기본적인 셋업방법 그리고 마이바티스와 스프링의 설정에 대한 튜토리얼등은 제공하지 않는다.
+마이바티스 스프링 연동을 시작하기 전에, 마이바티스와 스프링의 용어를 맞추는 일이 굉장히 중요했다. 이 문서는 배경지식이나 기본적인 셋업방법 그리고 마이바티스와 스프링의 설정에 대한 튜토리얼 등은 제공하지 않는다.
MyBatis-Spring requires following versions:
@@ -28,9 +28,9 @@ MyBatis-Spring requires following versions:
## 감사 인사
이 프로젝트가 실제로 만들어지게 도와준 모든 특별한 분들에게 정말 감사한다.
-알파벳 순서로 보면, 코딩및 테스트 그리고 문서화를 담당했던 Eduardo Macarron, Hunter Presnall, Putthiphong Boonphong;
+알파벳 순서로 보면, 코딩 및 테스트 그리고 문서화를 담당했던 Eduardo Macarron, Hunter Presnall, Putthiphong Boonphong;
그외 다양한 프로젝트 기여자인 Andrius Juozapaitis, Giovanni Cuccu, Mike Lanyon, Raj Nagappan, Tomas Pinos;
-그리고 마이바티스에 하위 프로젝트로 가져올수 있도록 많은 것을 찾아준 Simone Tripodi 에게 감사한다. ;)
+그리고 마이바티스에 하위 프로젝트로 가져올 수 있도록 많은 것을 찾아준 Simone Tripodi 에게 감사한다. ;)
이들이 없었다면 이 프로젝트는 존재하지 않았을 것이다.
## 이 문서가 더 나아지도록 도와주세요…
@@ -39,11 +39,11 @@ MyBatis-Spring requires following versions:
이 문서의 원본은 markdown 포맷이며 [프로젝트의 Git](https://github.com/mybatis/spring/tree/master/src/site)에서 찾을 수 있다. repository 를 fork 하고, 업데이트하고 pull request 를 보내주십시오.
-당신처럼 이 문서를 읽는 사람들에게 이 문서의 최고의 저자가 될수 있다!
+당신처럼 이 문서를 읽는 사람들에게 이 문서의 최고의 저자가 될 수 있다!
## 번역
-사용자들은 다음의 번역문서별로 마이바티스 스프링 연동모듈에 대해 알수 있다.
+사용자들은 다음의 번역 문서별로 마이바티스 스프링 연동 모듈에 대해 알 수 있다.
English
diff --git a/src/site/ko/markdown/mappers.md b/src/site/ko/markdown/mappers.md
index 0d3c2bdf78..d537db1e65 100644
--- a/src/site/ko/markdown/mappers.md
+++ b/src/site/ko/markdown/mappers.md
@@ -1,7 +1,7 @@
# 매퍼 주입
-`SqlSessionDaoSupport` 나 `SqlSessionTemplate` 를 직접적으로 사용하는 데이터 접근 객체(DAO)를 생성하기 보다, 마이바티스 스프링 연동모듈은 다른 빈에 직접 주입할 수 있는 쓰레드에 안전한 매퍼를 생성할 수 있다.
+`SqlSessionDaoSupport` 나 `SqlSessionTemplate` 를 직접적으로 사용하는 데이터 접근 객체(DAO)를 생성하기보다, 마이바티스 스프링 연동 모듈은 다른 빈에 직접 주입할 수 있는 쓰레드에 안전한 매퍼를 생성할 수 있다.
```xml
@@ -9,7 +9,7 @@
```
-한번 주입하고나면 매퍼는 애플리케이션 로직에서 사용할수 있는 준비가 된다.
+한번 주입하고 나면 매퍼는 애플리케이션 로직에서 사용할 수 있는 준비가 된다.
```java
public class FooServiceImpl implements FooService {
@@ -26,7 +26,7 @@ public class FooServiceImpl implements FooService {
}
```
-이 코드를 보면 `SqlSession`이나 마이바티스 객체가 보이지 않는다. 게다가 세션을 생성하거나 열고 닫을필요도 없어보인다. 마이바티스 스프링 연동모듈이 알아서 처리할 것이다.
+이 코드를 보면 `SqlSession`이나 마이바티스 객체가 보이지 않는다. 게다가 세션을 생성하거나 열고 닫을 필요도 없어 보인다. 마이바티스 스프링 연동 모듈이 알아서 처리할 것이다.
## 매퍼 등록하기
@@ -35,7 +35,7 @@ public class FooServiceImpl implements FooService {
### XML설정 사용
-매퍼는 다음처럼 XML설정파일에 `MapperFactoryBean`을 두는 것으로 스프링에 등록된다.
+매퍼는 다음처럼 XML설정 파일에 `MapperFactoryBean`을 두는 것으로 스프링에 등록된다.
```xml
@@ -45,10 +45,10 @@ public class FooServiceImpl implements FooService {
```
UserMapper가 매퍼 인터페이스와 같은 경로의 클래스패스에 마이바티스 XML매퍼 파일을 가지고 있다면 `MapperFactoryBean`이 자동으로 파싱할것이다.
-매퍼 XML파일을 다른 클래스패스에 두는게 아니라면 마이바티스 설정파일에 매퍼를 지정할 필요가 없다. 좀더 세부적인 정보는 `SqlSessionFactoryBean`의 [`configLocation`](factorybean.html) 프로퍼티를 살펴보자.
+매퍼 XML파일을 다른 클래스패스에 두는게 아니라면 마이바티스 설정 파일에 매퍼를 지정할 필요가 없다. 좀 더 세부적인 정보는 `SqlSessionFactoryBean`의 [`configLocation`](factorybean.html) 프로퍼티를 살펴보자.
`MapperFactoryBean`은 `SqlSessionFactory` 나 `SqlSessionTemplate`가 필요하다. `sqlSessionFactory` 와 `sqlSessionTemplate` 프로퍼티를 셋팅하면 된다.
-둘다 셋팅하면 `SqlSessionFactory`가 무시된다. 세션 팩토리 셋은 `SqlSessionTemplate`이 필요하고 `MapperFactoryBean`는 팩토리를 사용할것이다.
+둘 다 셋팅하면 `SqlSessionFactory`가 무시된다. 세션 팩토리 셋은 `SqlSessionTemplate`이 필요하고 `MapperFactoryBean`는 팩토리를 사용할 것이다.
### 자바설정 사용
@@ -67,15 +67,15 @@ public class MyBatisConfig {
## 매퍼 스캔
-하나씩 매퍼를 모두 등록할 필요가 없다. 대신 클래스패스를 지정해서 마이바티스 스프링 연동모듈의 자동스캔기능을 사용할 수 있다.
+하나씩 매퍼를 모두 등록할 필요가 없다. 대신 클래스패스를 지정해서 마이바티스 스프링 연동 모듈의 자동 스캔 기능을 사용할 수 있다.
-자동스캔을 사용하는데는 3가지 방법이 있다.
+자동 스캔을 사용하는 데는 3가지 방법이 있다.
* ` ` 엘리먼트 사용
* `@MapperScan` 애노테이션 사용
* 스프링 XML파일을 사용해서 `MapperScannerConfigurer`를 등록
-` ` 와 `@MapperScan` 모두 마이바티스 스프링 연동모듈 1.2.0에서 추가된 기능이다. `@MapperScan` 은 스프링 버전이 3.1이상이어야 한다.
+` ` 와 `@MapperScan` 모두 마이바티스 스프링 연동 모듈 1.2.0에서 추가된 기능이다. `@MapperScan` 은 스프링 버전이 3.1이상이어야 한다.
Since 2.0.2, mapper scanning feature support a option (`lazy-initialization`) that control lazy initialization enabled/disabled of mapper bean.
The motivation for adding this option is supporting a lazy initialization control feature supported by Spring Boot 2.2.
@@ -107,7 +107,7 @@ The `default-scope` apply to the mapper bean(`MapperFactoryBean`) when scope of
` ` XML엘리먼트는 스프링에서 제공하는 ` ` 엘리먼트와 매우 유사한 방법으로 매퍼를 검색할 것이다.
-샘플 XML설정을 아래에서 볼수 있다.
+샘플 XML설정을 아래에서 볼 수 있다.
```xml
```
-`base-package` 속성은 매퍼 인터페이스 파일이 있는 가장 상위 패키지를 지정하면 된다. 세미콜론이나 콤마를 구분자로 사용해서 한개 이상의 패키지를 셋팅할 수 있다.
+`base-package` 속성은 매퍼 인터페이스 파일이 있는 가장 상위 패키지를 지정하면 된다. 세미콜론이나 콤마를 구분자로 사용해서 한 개 이상의 패키지를 셋팅할 수 있다.
매퍼는 지정된 패키지에서 재귀적으로 하위 패키지를 모두 검색할 것이다.
` `이 자동으로 주입할 수 있는 `MapperFactoryBean`를 생성하기 때문에 `SqlSessionFactory` 나 `SqlSessionTemplate` 를 명시할 필요가 없다.
-하지만 한개 이상의 `DataSource`를 사용한다면 자동주입이 생각한데로 동작하지 않을수도 있다. 이 경우 사용할 빈 이름을 지정하기 위해 `factory-ref` 나 `template-ref` 속성을 사용할수 있다.
+하지만 한 개 이상의 `DataSource`를 사용한다면 자동 주입이 생각한 대로 동작하지 않을 수도 있다. 이 경우 사용할 빈 이름을 지정하기 위해 `factory-ref` 나 `template-ref` 속성을 사용할수 있다.
-` `은 마커(marker) 인터페이스나 애노테이션을 명시해서 생성되는 매퍼를 필터링할수도 있다. `annotation` 프로퍼티는 검색할 애노테이션을 지정한다.
-`marker-interface` 프로퍼티는 검색할 상위 인터페이스를 지정한다. 이 두개의 프로퍼티를 모두 지정하면, 매퍼는 두 조건을 모두 만족하는 인터페이스만을 추가한다.
-디폴트로 이 두가지 프로퍼티는 모두 null이다. 그래서 base-package프로퍼티에 설정된 패키지 아래 모든 인터페이스가 매퍼로 로드될 것이다.
+` `은 마커(marker) 인터페이스나 애노테이션을 명시해서 생성되는 매퍼를 필터링할 수 도 있다. `annotation` 프로퍼티는 검색할 애노테이션을 지정한다.
+`marker-interface` 프로퍼티는 검색할 상위 인터페이스를 지정한다. 이 두 개의 프로퍼티를 모두 지정하면, 매퍼는 두 조건을 모두 만족하는 인터페이스만을 추가한다.
+디폴트로 이 두 가지 프로퍼티는 모두 null이다. 그래서 base-package프로퍼티에 설정된 패키지 아래 모든 인터페이스가 매퍼로 로드될 것이다.
-발견된 매퍼는 자동검색된 컴포넌트를 위한 스프링의 디폴트 명명규칙 전략(see [the Spring reference document(Core Technologies -Naming autodetected components-)](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#beans-scanning-name-generator) 을 사용해서 빈이름이 명명된다.
-빈 이름을 정하는 애노테이션이 없다면 매퍼의 이름에서 첫글자를 소문자로 변환한 형태로 빈 이름을 사용할 것이다. `@Component` 나 JSR-330의 `@Named` 애노테이션이 있다면 애노테이션에 정의한 이름을 그대로 사용할 것이다.
+발견된 매퍼는 자동 검색된 컴포넌트를 위한 스프링의 디폴트 명명 규칙 전략(see [the Spring reference document(Core Technologies -Naming autodetected components-)](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#beans-scanning-name-generator) 을 사용해서 빈 이름이 명명된다.
+빈 이름을 정하는 애노테이션이 없다면 매퍼의 이름에서 첫 글자를 소문자로 변환한 형태로 빈 이름을 사용할 것이다. `@Component` 나 JSR-330의 `@Named` 애노테이션이 있다면 애노테이션에 정의한 이름을 그대로 사용할 것이다.
`annotation` 프로퍼티를 `org.springframework.stereotype.Component`, `jakarta.inject.Named`(Jakarta EE을 사용한다면) 또는 개발자가 스스로 작성한 애노테이션으로 셋팅할 수 있다.
그러면 애노테이션은 마커와 이름을 제공하는 역할로 동작할 것이다.
중요
-` ` 가 매퍼를 검색해서 등록을 하지 못할수도 있다. 매퍼는 인터페이스고 스프링에 빈으로 등록하기 위해서는 각각의 인터페이스를 찾기 위해 스캐너가 `MapperFactoryBean` 를 생성하는 방법을 알아야만 한다.
+` ` 가 매퍼를 검색해서 등록을 하지 못할 수도 있다. 매퍼는 인터페이스고 스프링에 빈으로 등록하기 위해서는 각각의 인터페이스를 찾기 위해 스캐너가 `MapperFactoryBean` 를 생성하는 방법을 알아야만 한다.
### @MapperScan
-`@Configuration` 라고 불리는 스프링의 자바설정을 사용한다면 ` `보다는 `@MapperScan`를 사용하길 선호할것이다.
+`@Configuration` 라고 불리는 스프링의 자바 설정을 사용한다면 ` `보다는 `@MapperScan`를 사용하길 선호할 것이다.
`@MapperScan` 애노테이션은 다음처럼 사용된다.
@@ -172,13 +172,13 @@ Since 2.0.4, If `basePackageClasses` or `basePackages` are not defined, scanning
```
-`sqlSessionFactory` 나 `sqlSessionTemplate`를 지정할 필요가 있다면 빈참조가 아닌 **빈이름**이 필요하다. `value` 프로퍼티는 빈 이름을 지정하고 `ref` 는 빈 참조를 지정하기 때문에 `value` 프로퍼티를 사용하자.
+`sqlSessionFactory` 나 `sqlSessionTemplate`를 지정할 필요가 있다면 빈 참조가 아닌 **빈 이름**이 필요하다. `value` 프로퍼티는 빈 이름을 지정하고 `ref` 는 빈 참조를 지정하기 때문에 `value` 프로퍼티를 사용하자.
```xml
```
중요
-`sqlSessionFactoryBean` 과 `sqlSessionTemplateBean` 프로퍼티는 마이바티스 스프링 연동모듈 1.0.2 버전 이상에서만 사용이 가능하다.
+`sqlSessionFactoryBean` 과 `sqlSessionTemplateBean` 프로퍼티는 마이바티스 스프링 연동 모듈 1.0.2 버전 이상에서만 사용이 가능하다.
하지만 `MapperScannerConfigurer`는 잦은 에러를 발생시키는 `PropertyPlaceholderConfigurer`보다 앞서 실행되기 때문에 이 프로퍼티들은 사용하지 말길 바란다(deprecated).
대신 새롭게 추가된 프로퍼티인 `sqlSessionFactoryBeanName` 과 `sqlSessionTemplateBeanName` 를 사용하도록 권한다.
diff --git a/src/site/ko/markdown/sqlsession.md b/src/site/ko/markdown/sqlsession.md
index 783f42df0f..d0e3458ac8 100644
--- a/src/site/ko/markdown/sqlsession.md
+++ b/src/site/ko/markdown/sqlsession.md
@@ -1,21 +1,21 @@
# SqlSession 사용
-마이바티스에서는 `SqlSession`를 생성하기 위해 `SqlSessionFactory`를 사용한다. 세션을 한번 생성하면 매핑구문을 실행하거나 커밋 또는 롤백을 하기 위해 세션을 사용할수 있다.
+마이바티스에서는 `SqlSession`를 생성하기 위해 `SqlSessionFactory`를 사용한다. 세션을 한번 생성하면 매핑구문을 실행하거나 커밋 또는 롤백을 하기 위해 세션을 사용할 수 있다.
마지막으로 더 이상 필요하지 않은 상태가 되면 세션을 닫는다. 마이바티스 스프링 연동모듈을 사용하면 `SqlSessionFactory`를 직접 사용할 필요가 없다.
왜냐하면, 스프링 트랜잭션 설정에 따라 자동으로 커밋 혹은 롤백을 수행하고 닫혀지는, 쓰레드에 안전한 `SqlSession` 개체가 스프링 빈에 주입될 수 있기 때문이다.
# SqlSessionTemplate
-`SqlSessionTemplate`은 마이바티스 스프링 연동모듈의 핵심이다. `SqlSessionTemplate`은 `SqlSession`을 구현하고 코드에서 `SqlSession`를 대체하는 역할을 한다.
-`SqlSessionTemplate` 은 쓰레드에 안전하고 여러개의 DAO나 매퍼에서 공유할수 있다.
+`SqlSessionTemplate`은 마이바티스 스프링 연동 모듈의 핵심이다. `SqlSessionTemplate`은 `SqlSession`을 구현하고 코드에서 `SqlSession`를 대체하는 역할을 한다.
+`SqlSessionTemplate` 은 쓰레드에 안전하고 여러 개의 DAO나 매퍼에서 공유할 수 있다.
-`getMapper()`에 의해 리턴된 매퍼가 가진 메서드를 포함해서 SQL을 처리하는 마이바티스 메서드를 호출할때 `SqlSessionTemplate`은 `SqlSession`이 현재의 스프링 트랜잭션에서 사용될수 있도록 보장한다.
-추가적으로 `SqlSessionTemplate`은 필요한 시점에 세션을 닫고, 커밋하거나 롤백하는 것을 포함한 세션의 생명주기를 관리한다. 또한 마이바티스 예외를 스프링의 `DataAccessException`로 변환하는 작업또한 처리한다.
+`getMapper()`에 의해 리턴된 매퍼가 가진 메서드를 포함해서 SQL을 처리하는 마이바티스 메서드를 호출할 때 `SqlSessionTemplate`은 `SqlSession`이 현재의 스프링 트랜잭션에서 사용될 수 있도록 보장한다.
+추가적으로 `SqlSessionTemplate`은 필요한 시점에 세션을 닫고, 커밋하거나 롤백하는 것을 포함한 세션의 생명주기를 관리한다. 또한 마이바티스 예외를 스프링의 `DataAccessException`로 변환하는 작업 또한 처리한다.
`SqlSessionTemplate`은 마이바티스의 디폴트 구현체인 `DefaultSqlSession` 대신 **항상** 사용된다.
-왜냐하면 템플릿은 스프링 트랜잭션의 일부처럼 사용될 수 있고 여러개 주입된 매퍼 클래스에 의해 사용되도록 쓰레드에 안전하다.
-동일한 애플리케이션에서 두개의 클래스간의 전환은 데이터 무결성 이슈를 야기할수 있다.
+왜냐하면 템플릿은 스프링 트랜잭션의 일부처럼 사용될 수 있고 여러 개 주입된 매퍼 클래스에 의해 사용되도록 쓰레드에 안전하다.
+동일한 애플리케이션에서 두 개의 클래스간 전환은 데이터 무결성 이슈를 야기할 수 있다.
`SqlSessionTemplate`은 생성자 인자로 `SqlSessionFactory`를 사용해서 생성될 수 있다.
@@ -59,7 +59,7 @@ public class UserDaoImpl implements UserDao {
```
-`SqlSessionTemplate`은 인자로 `ExecutorType`를 가지는 생성자를 가지고 있다. 이 인자는 예를들면 스프링 설정 XML을 다음처럼 설정해서 배치형태의 `SqlSession`를 만들수도 있다.
+`SqlSessionTemplate`은 인자로 `ExecutorType`를 가지는 생성자를 가지고 있다. 이 인자는 예를 들면 스프링 설정 XML을 다음처럼 설정해서 배치형태의 `SqlSession`를 만들 수도 있다.
```xml
@@ -94,14 +94,14 @@ public class UserService {
}
```
-이러한 설정형태는 `SqlSessionFactory`의 디폴트 형태가 아닌 다른형태로 메서드를 실행해야 할때만 사용할 필요가 있다.
+이러한 설정 형태는 `SqlSessionFactory`의 디폴트 형태가 아닌 다른 형태로 메서드를 실행해야 할 때만 사용할 필요가 있다.
-이러한 형태에 대해 굳이 경로를 하자면 메서드를 호출할때 `ExecutorType`이 다르면 이미 시작된 트랜잭션을 사용하지 **못할**것이다.
-다른 실행자(executor) 타입을 사용할때는 `SqlSessionTemplate`의 메서드를 구분된 트랜잭션(`PROPAGATION_REQUIRES_NEW`를 사용하는)이나 트랜잭션 외부에서 호출하는지 확실히해야 한다.
+이러한 형태에 대해 굳이 경로를 하자면 메서드를 호출할 때 `ExecutorType`이 다르면 이미 시작된 트랜잭션을 사용하지 **못할**것이다.
+다른 실행자(executor) 타입을 사용할 때는 `SqlSessionTemplate`의 메서드를 구분된 트랜잭션(`PROPAGATION_REQUIRES_NEW`를 사용하는)이나 트랜잭션 외부에서 호출하는지 확실히 해야 한다.
## SqlSessionDaoSupport
-`SqlSessionDaoSupport`는 `SqlSession`을 제공하는 추상클래스이다. `getSqlSession()`메서드를 호출해서 다음처럼 SQL을 처리하는 마이바티스 메서드를 호출하기 위해 사용할 `SqlSessionTemplate`을 얻을 수 있다.
+`SqlSessionDaoSupport`는 `SqlSession`을 제공하는 추상 클래스이다. `getSqlSession()`메서드를 호출해서 다음처럼 SQL을 처리하는 마이바티스 메서드를 호출하기 위해 사용할 `SqlSessionTemplate`을 얻을 수 있다.
```java
public class UserDaoImpl extends SqlSessionDaoSupport implements UserDao {
@@ -111,9 +111,9 @@ public class UserDaoImpl extends SqlSessionDaoSupport implements UserDao {
}
```
-대개 `MapperFactoryBean`은 추가적인 코드가 필요없기 때문에 이 클래스를 선호한다. 하지만 DAO에서 마이바티스가 필요하지 않고 구현된 클래스가 필요하지 않을때만 유용하다.
+대개 `MapperFactoryBean`은 추가적인 코드가 필요 없기 때문에 이 클래스를 선호한다. 하지만 DAO에서 마이바티스가 필요하지 않고 구현된 클래스가 필요하지 않을 때만 유용하다.
-`SqlSessionDaoSupport`는 `sqlSessionFactory` 와 `sqlSessionTemplate` 프로퍼티를 셋팅할 필요가 있다. 두개의 프로퍼티를 모두 셋팅하면 `sqlSessionFactory`는 무시된다.
+`SqlSessionDaoSupport`는 `sqlSessionFactory` 와 `sqlSessionTemplate` 프로퍼티를 셋팅할 필요가 있다. 두 개의 프로퍼티를 모두 셋팅하면 `sqlSessionFactory`는 무시된다.
`SqlSessionDaoSupport`의 하위클래스인 `UserDaoImpl`가 있다고 하면 스프링에서는 다음처럼 설정될 수 있다.
diff --git a/src/site/ko/markdown/transactions.md b/src/site/ko/markdown/transactions.md
index df84e8861d..f7ad754ef7 100644
--- a/src/site/ko/markdown/transactions.md
+++ b/src/site/ko/markdown/transactions.md
@@ -1,13 +1,13 @@
# Transactions
-마이바티스 스프링 연동모듈을 사용하는 중요한 이유중 하나는 마이바티스가 스프링 트랜잭션에 자연스럽게 연동될수 있다는 것이다.
+마이바티스 스프링 연동 모듈을 사용하는 중요한 이유 중 하나는 마이바티스가 스프링 트랜잭션에 자연스럽게 연동될 수 있다는 것이다.
마이바티스에 종속되는 새로운 트랜잭션 관리를 만드는 것보다는 마이바티스 스프링 연동모듈이 스프링의 `DataSourceTransactionManager`과 융합되는 것이 좋다.
-스프링 트랜잭션 관리자를 한번 설정하면, 대개의 경우처럼 스프링에서 트랜잭션을 설정할 수 있다. `@Transactional` 애노테이션과 AOP스타일의 설정 모두 지원한다.
-하나의 `SqlSession`객체가 생성되고 트랜잭션이 동작하는 동안 지속적으로 사용될것이다. 세션은 트랜잭션이 완료되면 적절히 커밋이 되거나 롤백될것이다.
+스프링 트랜잭션 관리자를 한 번 설정하면, 대개의 경우처럼 스프링에서 트랜잭션을 설정할 수 있다. `@Transactional` 애노테이션과 AOP스타일의 설정 모두 지원한다.
+하나의 `SqlSession`객체가 생성되고 트랜잭션이 동작하는 동안 지속적으로 사용될 것이다. 세션은 트랜잭션이 완료되면 적절히 커밋이 되거나 롤백될것이다.
-마이바티스 스프링 연동모듈은 한번 셋업되면 트랜잭션을 투명하게 관리한다. DAO클래스에 어떠한 추가적인 코드를 넣을 필요가 없다.
+마이바티스 스프링 연동 모듈은 한 번 셋업되면 트랜잭션을 투명하게 관리한다. DAO클래스에 어떠한 추가적인 코드를 넣을 필요가 없다.
## 표준 설정
@@ -30,9 +30,9 @@ public class DataSourceConfig {
}
```
-명시된 `DataSource`는 스프링을 사용할때 일반적으로 사용한다면 어떠한 JDBC `DataSource`도 될수 있다. JNDI룩업을 통해 얻어진 `DataSource`뿐 아니라 커넥션 풀링 기능도 포함한다.
+명시된 `DataSource`는 스프링을 사용할 때 일반적으로 사용한다면 어떠한 JDBC `DataSource`도 될 수 있다. JNDI룩업을 통해 얻어진 `DataSource`뿐 아니라 커넥션 풀링 기능도 포함한다.
-트랜잭션 관리자에 명시된 `DataSource`가 `SqlSessionFactoryBean`을 생성할때 사용된 것과 **반드시** 동일한 것이어야 하는 것만 꼭 기억하자. 그렇지 않으면 트랜잭션 관리가 제대로 되지 않을것이다.
+트랜잭션 관리자에 명시된 `DataSource`가 `SqlSessionFactoryBean`을 생성할 때 사용된 것과 **반드시** 동일한 것이어야 하는 것만 꼭 기억하자. 그렇지 않으면 트랜잭션 관리가 제대로 되지 않을 것이다.
## Container Managed Transactions
@@ -53,7 +53,7 @@ public class DataSourceConfig {
}
```
-이 설정에서, 마이바티스는 CMT와 함께 설정된 스프링 트랜잭션 리소스처럼 동작할 것이다. 스프링은 이미 설정된 트랜잭션을 사용해서 `SqlSession`을 이미 동작중인 트랜잭션에 넣을 것이다.
+이 설정에서, 마이바티스는 CMT와 함께 설정된 스프링 트랜잭션 리소스처럼 동작할 것이다. 스프링은 이미 설정된 트랜잭션을 사용해서 `SqlSession`을 이미 동작 중인 트랜잭션에 넣을 것이다.
시작된 트랜잭션이 없고 트랜잭션이 필요한 경우라면 스프링은 새로운 컨테이너 관리 트랜잭션을 시작할 것이다.
CMT는 사용하지만 스프링 트랜잭션 관리를 원하지 **않는다면** 어떠한 스프링 트랜잭션 관리자를 설정해서도 **안되고** 마이바티스 `ManagedTransactionFactory`를 사용하기 위해 `SqlSessionFactoryBean`를 설정**해야만** 한다.
@@ -83,10 +83,10 @@ public class MyBatisConfig {
## Programmatic Transaction Management
-마이바티스 `SqlSession`은 트랜잭션을 제어하는 메서드를 제공한다. 하지만 마이바티스 스프링 연동모듈은 빈을 스프링이 관리하는 `SqlSession`이나 스프링이 관리하는 매퍼에 주입한다.
+마이바티스 `SqlSession`은 트랜잭션을 제어하는 메서드를 제공한다. 하지만 마이바티스 스프링 연동 모듈은 빈을 스프링이 관리하는 `SqlSession`이나 스프링이 관리하는 매퍼에 주입한다.
이 말은 스프링이 **항상** 트랜잭션을 관리한다는 뜻이다.
-스프링이 관리하는 `SqlSession`에서는 `SqlSession.commit()`, `SqlSession.rollback()` 또는 `SqlSession.close()` 메서드를 호출할수가 없다.
+스프링이 관리하는 `SqlSession`에서는 `SqlSession.commit()`, `SqlSession.rollback()` 또는 `SqlSession.close()` 메서드를 호출할 수가 없다.
그럼에도 불구하고 이 메서드들을 사용하면 `UnsupportedOperationException` 예외가 발생한다. 이러한 메서드는 주입된 매퍼 클래스에서는 사용할 수 없다.
JDBC연결의 자동커밋 설정을 어떻게 하더라도 스프링 트랜잭션 밖의 `SqlSession` 데이터 메서드나 매퍼 메서드의 실행은 자동으로 커밋된다.
diff --git a/src/site/ko/markdown/using-api.md b/src/site/ko/markdown/using-api.md
index 3894e1d396..e686106e00 100644
--- a/src/site/ko/markdown/using-api.md
+++ b/src/site/ko/markdown/using-api.md
@@ -21,7 +21,7 @@ public class UserDaoImpl implements UserDao {
}
```
-이 방법은 **신중히** 사용하자. 왜냐하면 잘못사용하면 런타임 에러나 데이터 문제등을 야기할수 있기 때문이다. API를 직접 사용할때는 다음의 규칙들에 유의해야 한다.
+이 방법은 **신중히** 사용하자. 왜냐하면 잘못 사용하면 런타임 에러나 데이터 문제 등을 야기할 수 있기 때문이다. API를 직접 사용할 때는 다음의 규칙들에 유의해야 한다.
* 스프링 트랜잭션에 **속하지 않고** 별도의 트랜잭션에서 동작한다.
* `SqlSession`이 스프링 트랜잭션 관리자가 사용하는 `DataSource`를 사용하고 이미 트랜잭션이 동작하고 있다면 이 코드는 예외를 **발생시킬 것이다**.