| [ java ] in KIDS 글 쓴 이(By): hell (나누구야) 날 짜 (Date): 1997년12월28일(일) 09시30분59초 ROK 제 목(Title): [JDBC] Getting Started 한글판 (2-3) 2.1.6 SQL문들을 전송하기 일단 연결이 되면, 데이터베이스에 SQL문을 전송하는데 사용되어진다. JDBC는 전송될 수 있는 SQL문의 종류에 제한을 두지 않는다. 이것은 데이터베이스-특정 SQL문, 심지어 non-SQL 문들의 사용을 허용하는 대단한 융통성을 제공한다. 그러나, 사용자는 데이터베이스가 전송되어지는 SQL문을 처리할수 있고 결과를 허용할 수 있는지를 확인해야한다. 예를 들어, 저장 프로시져를 지원하지 않는 DBMS로 저장프로시져 호출을 보내는 어플리케이션은 실행되지 않고 예외상황을 발생할 것이다. JDBC는 드라이버가 JDBC COMPLIANT로 지명되어지기 위해서 적어도 ANSI SQL-2 Entry Level 능력들을 제공할 것을 요구한다. 이것은 사용자가 적어도 이러한 기능의 표준 레벨에 의지할 수 있음을 의미한다. JDBC는 SQL문들을 데이터베이스로 전송하기 위해 세가지 클래스를 제공하며, Connection 인터페이스에 있는 세가지 메쏘드들을 가지고 이러한 클래스들의 인스턴스를 생성한다. 세가지 클래스와 Connection 인터페이스에 있는 메쏘드는 다음과 같다.: 1.Statement - createStatement 메쏘드에 의해 생성된다. Statement 객체는 간단한 SQL 문들을 전송하는데 사용된다. 2.PreparedStatement - prepareStatement 메쏘드에 의해 생성된다. PreparedStatement 객체는 하나이상의 입력 인자를 매개변수(IN 매개변수)로 가지는 SQL문을 위해 사용되어진다. PreparedStatement는 IN 매개변수의 값을 설정하는 메쏘드들을 가지며, 이것들은 SQL문이 실행되어질 때 데이터베이스로 전송된다. PreparedStatement의 인스턴스는 Statement를 상속하기 때문에 Statement 메쏘드들을 포함한다. PreparedStatement 객체는 미리 컴파일되고 이후의 사용의 위해 저장되기 때문에 Statement 객체보다 더욱 효과적이 될 수 있는 잠재력을 가진다. 3.CallableStatement - prepareCall 메쏘드에 의해 생성된다. CallableStatement객체는 SQL 저장 프로시져들-함수를 호출하는 것처럼 이름에 의해 호출되어지는(call by name) SQL문의 그룹-을 실행하는데 사용된다. CallableStatement 객체는 PreparedStatement로부터 IN 매개변수를 처리하기 위한 메쏘드를 상속받고 OUT과 INOUT 매개변수를 처리하기 위한 메쏘드를 추가한다. 다음은 다른 형태의 SQL문들을 생성하는데 어떠한 Connection 메쏘드가 적당한가를 결정하기 위한 방법을 제공한다. createStatement 메쏘드는 다음을 위해 사용되어진다. 간단한 SQL문들(매개변수 없음) prepareStetement 메쏘드는 다음을 위해 사용되어진다. 하나 이상의 IN 매개변수들을 가지는 SQL문들 자주 실행되어질 간단한 SQL문들 prepareCall 메쏘드는 다음을 위해 사용된다. 저장 프로시져들의 호출 2.1.7 트랜젝션들 트랜젝션은 실행되고 완결된 다음 회부되거나 되돌아오는 하나 이상의 SQL문으로 구성된다. commit 나 rollback 메쏘드가 호출될때, 현재 트랜젝션이 끝나고 다른 것이 시작된다. 새로운 연결은 디폴트로 auto-commit 모드이다. 이것은 SQL문이 완결될때에, commit 메쏘드가 그 SQL문을 자동적으로 요청하게 됨을 의미한다. 이러한 경우에 각 SQL문을 개별적으로 회부되어지기 때문에, 트랙젝션을 오직 하나의 SQL문으로 구성된다. 만약 auto-commit 모드가 비활성화 된다면, 트랙젝션은 commit나 rollback 메쏘드가 명백하게 호출되기 전까지는 종료되지 않는다. 따라서 트랜젝션은 commit나 rollback 메쏘드의 마지막 호출 이후에 실행되어지는 모든 SQL문을 포함할 것이다. 이러한 두 번째 경우에서, 트랙젝션에 있는 모든 SQL문들은 그룹으로써 회부되거나 되돌아온다. commit 메쏘드는 SQL문이 데이터베이스에 만드는 변화를 영구적으로 만들고, 또한 트랜젝션에 의한 어떠한 락들도 풀어놓는다. rollback 메쏘드는 변화들을 취소할 것이다. 때때로 사용자는 다른 하나가 원하지 않는다면 효과를 가지는 변화를 원하지 않을 것이다. 이것은 auto-commit를 비활성화 시키고 갱신된 두 개를 하나의 트랜젝션으로 그룹지음으로써 완성할 수 있다. 만약 두 개의 갱신이 모두 성공했다면 효과를 영구히 하기위해서 commint 메쏘드가 호출되고, 하나가 실패하거나 두 개 모두 실패하면 갱신이 실행되기 전에 있던 값을 다시 저장하기 위해서 rollback 메쏘드가 호출된다. 대부분의 JDBC 드라이버들은 트랙젝션을 지원한다. 사실상 JDBC-COMPLIANT 드라이버들은 트랜젝션을 지원해야한다. DatabaseMetaData는 DBMS가 제공하는 트랜젝션 지원 레벨을 설명하는 정보를 준다. 2.1.8 트랜젝션 분리 레벨들 만약 DBMS가 트랜젝션 처리를 지원한다면, 동시에 하나의 데이터베이스에서 두 개의 트랜젝션이 동작할 때 일어날 수 있는 잠재적인 충돌을 관리하는 방법을 가지고 있을 것이다. 사용자는 잠재적인 충돌들을 해결하는데 DBMS가 어떠한 보호 레벨을 사용할 수 있는가를 나타내는 트랜젝션 분리 레벨을 지정할 수 있다. 예를 들어, 한 트랜젝션이 값을 바꾸고 변화가 확정되거나 취소되기전에 두 번째 트랜젝션이 그 값을 읽을 때 무엇이 발생하는가? 허용이 된다면, 첫 번째 트랜젝션이 취소될때에 두 번째 트랜젝션에 의해 읽어진 변화된 값이 유효하지 않게 되는가? JDBC 사용자는 변화가 영구히 되기전에 값을 읽을수 있도록 다음의 코드를 가지고 DBMS에게 명령할 수 있다. 여기서 con은 현재의 연결이다.: con.setTransactionIsolation(TRANSACTION_READ_UNCOMMITTED); 트랙젝션 분리 레벨이 높으면 높을수록, 충돌을 피하기위해서 더욱 주의를 해야한다. Connection 인터페이스는 트랜젝션이 전혀 지원되지 않는 것을 가장 낮게 그리고 하나의 트랜젝션이 데이터베이스상에서 동작중에 있는동안 다른 트랜젝션들이 그 트랜젝션에 의해 읽혀진 데이터에 어떠한 변화도 만들지 않는 것을 가장 높게 하여 5개의 레벨을 정의한다. 전형적으로 분리 레벨이 높으면 높을수록 어플리케이션의 속도는 더욱 느려진다. (왜냐하면 락 오버헤드가 증가하고 사용자들 사이에 동시발생이 감소하기 때문이다.) 개발자는 어떤 분리 레벨을 사용할 것인가에 대해 결정할 때 성능을 위한 요구와 데이터 일관성을 위한 요구를 비교 평가해야만 한다. 물론 실제적으로 지원될 수 있는 레벨은 사용하는 DBMS의 능력에 좌우된다. 새로운 Connection 객체를 생성할때에 트랜젝션 분리 레벨은 드라이버에 의존하지만 보통 데이터베이스에 디폴트이다. 사용자는 트랜젝션 분리 레벨을 변경하기 위해서 setIsolationLevel 메쏘드를 호출할 것이고 새로운 레벨은 사실상 연결 부분의 나머지가 될 것이다. 단지 하나의 트랜젝션을 위해 트랜젝션 분리 레벨을 바꾸는 경우에는 트랜젝션이 시작하기 전에 설정하고 트랜젝션이 종료된 후에는 재설정한다. 트랜젝션 도중에 분리레벨을 변경하는 것을 바람직하지 않다. 왜냐하면 이것은 commit 메쏘드를 즉시 호출을 하여 그 시점까지의 어떠한 변화들을 영구적으로 만들기 때문이다. ~~moom~~ ~~moom~~ ~~moom~~ ~~moom~~ ~~moom~~ ~~moom~~ ~~moom~~ ~~moom~~ ~~moom~ KAIST전기및전자공학과학부96김태홍 URL :: http://volt.kaist.ac.kr/~dodo dodo@ohm dodo@csqueen dodo96@nownuri hell@kids nextism@ara ~~moom~~ ~~moom~~ ~~moom~~ ~~moom~~ ~~moom~~ ~~moom~~ ~~moom~~ ~~moom~~ ~~moom~ |