iotworks.co.kr

1. AJAX (Asynchronous Javascript And Xmlhttp)

Ajax(Asynchronous JavaScript and XML) 혹은 AJAX는 대화식 웹 어플리케이션의 제작을 위해 아래와 같은 조합을 이용하는 웹 개발 기법이다:
표현 정보를 위한 HTML (또는 XHTML) 과 CSS
동적인 화면 출력 및 표시 정보와의 상호작용을 위한 DOM, 자바스크립트
웹 서버와 비동기적으로 데이터를 교환하고 조작하기 위한 XML, XSLT, XMLHttpRequest (Ajax 어플리케이션은 XML/XSLT 대신 미리 정의된 HTML 이나 일반 텍스트, JSON, JSON-RPC를 이용할 수 있다).
DHTML과 같이 Ajax는 자체가 하나의 특정한 기술을 말하는 것이 아니며, 함께 사용하는 기술의 묶음을 지칭하는 용어이다.
Ajax 어플리케이션은 실행을 위한 플랫폼으로 위에서 열거한 기술들을 지원하는 웹 브라우저를 이용한다. 이것을 지원하는 브라우저로는 모질라 파이어폭스, 인터넷 익스플로러, 오페라, 사파리 등이 있다.

 

2. Ajax 어플리케이션은 기존의 웹 어플리케이션과 무엇이 다른가

기존의 웹 어플리케이션

폼을 채우고 제출(submit)을 하면, 웹 서버로 요청을 보내도록 한다. 웹 서버는 전송된 내용에 따라서 새로운 웹 페이지를 작성하여 결과물을 되돌려준다.
이때 최초에 폼을 가지고 있던 사이트와 사용자가 이 폼을 채워 결과물로서 되돌려 받은 두 페이지 사이에 중복되는 HTML코드로 인해 많은 대역폭을 낭비하게 된다.
네이티브 어플리케이션과 비교할 때 복잡한 대화형 사용자 인터페이스를 작성하기가 어렵다.

Ajax 어플리케이션

필요한 데이터만을 주도록 웹 서버에 요청할 수 있다.
보통 SOAP나 XML 기반의 웹 서비스 언어를 사용하며, 웹 서버의 응답을 처리하기 위해 클라이언트 쪽에서 자바스크립트를 쓴다.
그 결과로 웹 브라우저와 웹 서버 사이의 교환되는 데이터량이 줄어들기 때문에 어플리케이션의 응답성이 좋아진다. 요청을 주는 수많은 컴퓨터에서 이 같은 일이 일어나기 때문에, 전체적인 웹 서버 처리량도 줄어들게 된다

 

3. AJAX.NET

http://ajax.schwarz-interactive.de/csharpsample/default.aspx
이 공통 라이브러리는 ASP.NET에서 작성한 메소드를 그 이름 그대로 자바스크립트에서 호출할 수 있게 해준다.(동기/비동기)

 

* 웹폼 메서드

[Ajax.AjaxMethod]
public string Test(string s)
{
 string strReturn = s + " World";
 return strReturn;
}

* 자바스크립트에서 바로 웹폼 메서드를 호출

function btn1_onclick()
{
    var response = WebForm1.Test(“Hello ");
    alert(response.value);
}

 

4. AJAX.NET 아키텍처

기존에는 XmlHttp를 통해서 웹 페이지 혹은 웹 서비스를 호출하는 함수를 만들어야 했는데, AJAX.NET은 이 라이브러리를 참조하고 AjaxMethod 어트리뷰트를 추가하면 그런 함수를 자동으로 렌더링시켜주게 된다.

5. AJAX.NET 사용법

 

Step1. ajax.dll 참조
Step2. 다음 내용을 Web.Config에 추가

 

<configuration>
  <system.web>
    <httpHandlers>
    <add verb="POST,GET" path="ajax/*.ashx" type="Ajax.PageHandlerFactory, Ajax" />
    </httpHandlers>      ...
  <system.web>
</configuration>

Step3. 페이지 로드에 다음을 추가

 

private void Page_Load(object sender, EventArgs e){
      Ajax.Utility.RegisterTypeForAjax(typeof(Index));     
      //... 
   }

Step4. AjaxMethod를 작성하고, 스크립트에서 호출(위의 예제 참조)

ASP.NET 페이지 요구시 처리 과정
 - *.aspx
 - 클라이언트가 특정 페이지를 요구할 때마다 메모리 상에 페이지 객체는 생성, 소멸까지 일련의 과정을 거친다.

1. Init
 - 페이지 객체가 생성된 후 초기화 단계
 - 뷰스테이트 값 복구 전 단계, 저확한 컨트롤 참조 불확실
 - 이벤트 핸들러 매칭이나, 컨트롤 동적 로딩에 적합

2. ViewState복구
 - 뷰스테이트 복구 단계
 - 페이지 처음 요청시 건너뜀

2.5 다시 게시된 데이터 처리
 - 들어오는 폼 데이터를 처리하고, 그에 알맞게 속성을 업데이트합니다.
 - 다시 게시된 데이터를 처리하는 컨트롤만 이 단계를 수행합니다.

3. Load **
 - 뷰스테이트 값이 복구가 완료된 단계
 - 서버 큰트롤에 접근 가능(정확한 값을 가지고 있는 상태)
 - 모든 컨트롤이 탑재되고 값이 복구된 상태
 - 가장 많이 코딩하는 장소

4. PostBack 이벤트 처리 **
 - 사용자가 발행한 이벤트 처리 단계
 - 페이지가 처음 요청될 때는 이 단계는 건너뜀(IsPostBack이 false일때)

5. PreRender
 - 컨트롤을 랜더링하기 바로 전 단계
 - 처리 순서로 인해 발생하는 논리 문제를 해결하기 위해 Load해서 해야할 처리를 여기서 대신 가능

5.5 ViewState 저장
 - 컨트롤의 상태를 저장, 클라이언트에게 되돌려줌

6. Render
 - 컨트롤을 출력할 HTML로 랜더링 하는 단계

7. UnLoad
 - 페이지 객체가 소멸되기 전에 발생하는 단계
 - 페이지 요청시 항상 실행된다.(try-catch에서 finally처럼)
 - 클린업 코드 처리(리소스 반환)
 - 뷰스테이트 처리는  여기서 안함(아무 소용 X)

VS.NET으로 ASP.NET 개발을 하다보면, 다음과 같은 에러를 접할때가 있다.

에러페이지의 내용을 요약하면 '어셈블리의 매니페스트 정의가 어셈블리 참조와 일치하지 않습니다.' 이며,

이 에러는 참조당하는(참조하는이 아닌) 클래스가 있는 어셈블리의 매타정보(매니페스트)의 버전이 변경되었을때 발생한다.
겁나 어려운 말이므로 그림으로 설명하면..




한 프로젝트안에서 A클래스를 참조하는 B클래스가 있을경우, A 혹은, B클래스만 수정이 된다 하여도 빌드가 프로젝트단위(한 어셈블리)로 되기때문에 참조관계에 아무 문제가 없다.




하지만 다른 프로젝트의 클래스를 참조할때는 다르다.
프로젝트 AA를 빌드하여 어셈블리 AA.dll를 생성하고 이를 참조하는 프로젝트 BB 를 빌드하여 어셈블리 BB.dll를 생성했다.
그러면 BB.dll은 AA.dll를 참조하여 관련기능이 작동되는데, 이때 참조는 단순히 파일경로만으로 참조하는 것이 아니라 AssemblyInfo.cs(혹은 AssemblyInfo.vb) 를 참조하여 버전까지 확인을 한다.
즉 BB.dll를 빌드할때 AA.dll의 버전이 1.0.0.1 이 였는데, AA.dll에 수정사항이 생겨서 다시 빌드하여 버전이 1.0.02 로 바뀌였다면, BB.dll은 참조오류를 발생하고 그게 바로 위에 보이는 '어셈블리의 매니페스트 정의가 어셈블리 참조와 일치하지 않습니다.'  이다.

쉽게 말하면, '이놈은 파일명은 같은데, 내가 알던 그놈이 아이다.' 란 에러다. (근데, 겁나 어렵게 적혀있다. ㅡ ㅡa)



관련사항을 정리해보면.
.NET은 프로젝트 단위로 AssemblyInfo.cs(혹은 AssemblyInfo.vb) 를 가지고 있다.
이 파일은 빌드해서 생성되는 어셈블리에 대한 메타정보를 담고 있는 파일로서 매니페스트라 한다.
열어보면 중간쯤 어셈블리 버전에 대한 내용이 기본값으로 다음과 같이 들어가 있다.

기본 주석을 보면 알겠지만 위처럼 1.0.* 라고 넣으면 빌드할때 마다 버전이 자동으로 올라간다.
그러므로 위의 그림같은 경우, AA.dll 만 빌드를 할경우 버전이 자동으로 바뀌므로 기존버전을 참조하고 있던 다른 어셈블리에서 에러가 나는 거다.

그러므로 다음처럼 고정식으로 바꾸고 수동으로 필요에 따라 버전정보를 바꿔주면 위 에러를 해결할 수 있다.

물론 이 에러는 어셈블리 메타정보(매니페스트)의 다른 내용이 바뀌어도 발생하지만, 개발자가 손대지 않는데 자동으로 바뀌는 것은 아니므로, 버전만 신경쓰면 될것 같다.

트랜잭션 모델 선택

트랜잭션 모델을 선택하기 전에 트랜잭션이 필요한지 여부를 고려해야 합니다. 트랜잭션은 서버 응용 프로그램에서 소비되는 가장 비용이 높은 단일 리소스이며 불필요하게 사용할 경우 확장성을 감소시킵니다. 트랜잭션 사용과 관련된 다음 지침을 고려하십시오.

• 일련의 작업에 대해 잠금을 획득하고 ACID 규칙을 강제로 적용해야 하는 경우에만 트랜잭션을 수행합니다.
• 가능한 한 트랜잭션을 짧게 유지하여 데이터베이스 잠금을 유지하는 시간을 최소화합니다.
• 트랜잭션 수명을 클라이언트가 제어할 수 없도록 합니다.
• 개별 SQL 문에 대해서는 트랜잭션을 사용하지 않습니다. SQL Server는 각 문을 개별 트랜잭션으로 자동으로 실행합니다.

자동 트랜잭션과 수동 트랜잭션

자동 트랜잭션을 사용하면 특히 여러 구성 요소가 데이터베이스 업데이트를 수행하는 경우 프로그래밍 모델이 다소 간소화됩니다. 수동 로컬 트랜잭션을 사용하면 Microsoft DTC와의 상호 작용이 필요하지 않기 때문에 항상 속도가 더 빠릅니다. 성능 감소가 줄어들긴 하지만 단일 로컬 리소스 관리자(예: SQL Server)에 대해 자동 트랜잭션을 사용하는 경우, 수동의 로컬 트랜잭션은 DTC와의 불필요한 상호 프로세스 통신(IPC)을 방지하기 때문에 자동 트랜잭션이 수동 트랜잭션보다 느립니다.

다음 경우에 수동 트랜잭션을 사용하십시오.

• 단일 데이터베이스에 대해 트랜잭션을 수행합니다.

다음 경우에 자동 트랜잭션을 사용하십시오.

• 단일 트랜잭션을 여러 원격 데이터베이스로 확장할 수 있어야 합니다.
• 단일 트랜잭션에서 여러 리소스 관리자(예: 데이터베이스 및 Windows 2000 Message Queuing(이전의 MSMQ))를 포함해야 합니다.

참고 트랜잭션 모델은 혼합하지 마십시오. 하나만 선택해서 사용하십시오.

성능이 충분하다고 여겨지는 응용 프로그램 시나리오의 경우에는 프로그래밍 모델을 단순화하기 위해 단일 데이터베이스의 경우라도 자동 트랜잭션을 사용하는 것이 바람직합니다. 자동 트랜잭션을 사용하면 여러 구성 요소에서 동일 트랜잭션의 일부인 작업을 쉽게 수행할 수 있습니다.

수동 트랜잭션 사용

수동 트랜잭션의 경우 구성 요소 코드 또는 저장 프로시저에서 각각 ADO.NET 또는 Transact-SQL의 트랜잭션 지원 기능을 직접 사용하는 코드를 작성합니다. 대부분의 경우 이 방식은 뛰어난 캡슐화 성능을 제공하고 성능적인 관점에서 ADO.NET 코드로 트랜잭션을 수행하는 것과 비슷하기 때문에 저장 프로시저에서 트랜잭션을 제어할 수 있어야 합니다.

ADO.NET에서 수동 트랜잭션 수행

ADO.NET은 새 트랜잭션을 시작하고 커밋 또는 롤백 여부를 명시적으로 제어할 수 있는 트랜잭션을 지원합니다. 트랜잭션 개체는 단일 데이터베이스 연결과 연결되어 있으며 연결 개체의 BeginTransaction 메서드로 얻어집니다. 이 메서드를 호출해도 이후의 명령이 이 트랜잭션의 컨텍스트로 실행되지는 않습니다. 그렇게 하려면 명령의 Transaction 속성을 설정하여 각 명령을 트랜잭션과 명시적으로 연결해야 합니다. 트랜잭션 개체와 여러 명령 개체를 연결하면 단일 트랜잭션의 단일 데이터베이스에 대해 여러 작업을 그룹화합니다.

ADO.NET 트랜잭션 코드 사용 예를 보려면 부록에서 ADO.NET 수동 트랜잭션 코딩 방법을 참조하십시오.

추가 정보

• ADO.NET 수동 트랜잭션의 기본 격리 수준은 Read Committed이므로 데이터가 읽혀지는 동안 데이터베이스가 공유 잠금을 유지하지만 트랜잭션이 끝나기 전에 데이터를 변경할 수 있습니다. 따라서 반복되지 않은 읽기 또는 가상 데이터가 발생할 수 있습니다. 트랜잭션 개체의 IsolationLevel 속성을 IsolationLevel 열거 유형에서 정의된 열거 값 중 하나로 설정하여 격리 수준을 변경할 수 있습니다.
• 트랜잭션에 적합한 격리 수준을 선택할 때는 주의를 기울여야 합니다. 이 때 사용자는 데이터 일관성과 성능 중에서 하나를 선택해야 합니다. 최상의 격리 수준(직렬화)은 절대적인 데이터 일관성을 제공하지만 전반적인 시스템 처리량이 저하됩니다. 격리 수준이 낮으면 응용 프로그램의 확장성이 향상되지만 동시에 데이터 불일치로 인한 오류 발생 가능성이 높아집니다. 데이터 읽기 작업을 수행하고 쓰기 작업은 거의 수행하지 않는 시스템의 경우 낮은 격리 수준이 적합합니다.
• 적합한 트랜잭션 격리 수준 선택에 대한 자세한 내용을 보려면 Microsoft Press 책, Inside SQL Server 2000(저자: Kalen Delaney)을 참조하십시오.

저장 프로시저로 수동 트랜잭션 수행

또한 저장 프로시저에서 Transact-SQL 문을 사용하여 수동 트랜잭션을 직접 제어할 수 있습니다. 예를 들어 BEGIN TRANSACTION, END TRANSACTION 및 ROLLBACK TRANSACTION과 같은 Transact-SQL 트랜잭션 문을 사용하는 단일 저장 프로시저를 사용하여 트랜잭션 작업을 수행할 수 있습니다.

추가 정보

• 필요한 경우 저장 프로시저에서 SET TRANSACTION ISOLATION LEVEL 문을 사용하여 트랜잭션 격리 수준을 제어할 수 있습니다. Read Committed는 SQL Server 기본값입니다. SQL Server 격리 수준에 대한 자세한 내용은 SQL Server 온라인 설명서의 "관계 데이터 액세스 및 변경" 섹션의 격리 수준을 참조하십시오.
• Transact-SQL 트랜잭션 문을 사용하여 트랜잭션 업데이트 수행 방법을 보여 주는 코드 예제를 보려면 부록에 있는 Transact-SQL로 트랜잭션을 수행하는 방법을 참조하십시오.

자동 트랜잭션 사용

자동 트랜잭션은 새로운 트랜잭션을 명시적으로 시작하거나 트랜잭션을 명시적으로 커밋 또는 취소할 필요가 없기 때문에 프로그래밍 모델을 단순화합니다. 하지만 자동 트랜잭션의 가장 중요한 장점은 DTC와 함께 작동할 수 있다는 점입니다. 따라서 단일 트랜잭션을 여러 분산 데이터 원본으로 확장할 수 있습니다. 대규모 분산 응용 프로그램의 경우 이러한 장점은 매우 유용할 수 있습니다. DTC를 직접 프로그래밍하여 분산 트랜잭션을 수동으로 제어할 수 있는 경우라도 자동 트랜잭션은 작업을 크게 간소화할 수 있으며 구성 요소 기반 시스템에 맞게 디자인되었습니다. 예를 들어 단일 트랜잭션으로 구성된 작업을 수행하도록 여러 구성 요소를 선언적으로 쉽게 구성할 수 있습니다.

자동 트랜잭션은 COM+에서 제공되는 분산 트랜잭션 지원 기능에 의존하며, 그 결과 서비스 구성 요소(즉, ServicedComponent 클래스에서 파생된 구성 요소)에서 자동 트랜잭션을 사용할 수 있습니다.

자동 트랜잭션에 대한 클래스를 구성하려면

• System.EnterpriseServices 이름 공간 내에 있는 ServicedComponent 클래스로부터 클래스를 파생합니다.
• Transaction 특성을 사용하여 클래스의 트랜잭션 요구 사항을 정의합니다. TransactionOption 열거 유형으로부터 제공된 값은 클래스가 COM+ 카탈로그에서 구성되는 방법을 결정합니다. 이 특성으로 설정할 수 있는 다른 속성에는 트랜잭션 격리 수준과 제한 시간이 포함됩니다.
• 트랜잭션 결과를 명시적으로 선택해야 하는 경우를 방지하기 위해 AutoComplete 특성으로 메서드를 주석 처리할 수 있습니다. 이러한 메서드가 예외를 발생시키면 트랜잭션이 자동으로 취소됩니다. 필요한 경우 트랜잭션 결과를 직접 선택할 수도 있습니다. 자세한 내용은 이 문서의 후반에 있는 트랜잭션 결과 확인을 참조하십시오.

추가 정보

• COM+ 자동 트랜잭션에 대한 자세한 내용을 보려면 플랫폼 SDK 설명서에서 "COM+를 통한 자동 트랜잭션"을 찾아 보십시오.
• 트랜잭션 .NET 클래스 예를 보려면 부록에 있는 트랜잭션 .NET 클래스를 코딩하는 방법을 참조하십시오.

트랜잭션 격리 수준 구성

COM+ 버전1.0(Windows 2000에서 실행 중인 COM+)에 대한 트랜잭션 격리 수준은 직렬화됩니다. 이 수준은 최고의 격리 수준을 제공하지만 성능 감소를 수반합니다. 관련된 리소스 관리자(일반적으로 데이터베이스)가 트랜잭션 기간 동안 읽기 및 쓰기 잠금을 모두 유지해야 하기 때문에 시스템의 전반적인 처리량이 감소됩니다. 이 기간 동안 다른 모든 트랜잭션이 차단되어 응용 프로그램의 확장 성능에 심각한 영향을 줄 수 있습니다.

Microsoft Windows .NET과 함께 제공되는 COM+ 버전 1.5를 사용하면 트랜잭션 격리 수준을 구성 요소별 기반에 따라 COM+ 카탈로그에 구성할 수 있습니다. 트랜잭션의 루트 구성 요소와 연결된 설정은 트랜잭션의 격리 수준을 결정합니다. 또한 동일 트랜잭션 스트림의 일부인 내부 하위 구성 요소의 트랜잭션 수준은 루트 구성 요소에서 정의된 것보다 높지 않아야 합니다. 격리 수준이 높으면 하위 구성 요소가 인스턴스화될 때 오류가 발생합니다.

.NET 관리 클래스의 경우 Transaction 특성은 공용 Isolation 속성을 지원합니다. 이 속성을 사용하여 다음 코드에 표시된 것과 같이 특정 격리 수준을 선언적으로 지정할 수 있습니다.

 [Transaction(TransactionOption.Supported, Isolation=TransactionIsolationLevel.ReadCommitted)]

public class Account : ServicedComponent

{

  . . .

}

  

추가 정보

• 구성 가능한 트랜잭션 격리 수준 및 기타 Windows .NET COM+ 향상 기능에 대한 자세한 내용은 http://msdn.microsoft.com/msdnmag/issues/01/08/ComXP/default.aspx (영문)에서 MSDN Magazine 문서, "Windows XP: COM+ 1.5 혁신 기술로 구성 요소를 더욱 강력하게 만들기"를 참조하십시오

트랜잭션 결과 확인

자동 트랜잭션의 결과는 단일 트랜잭션 스트림의 모든 트랜잭션 구성 요소 컨텍스트에서 일관성 플래그와 함께 트랜잭션 취소 플래그의 상태로 제어됩니다. 트랜잭션 결과는 트랜잭션 스트림의 루트 구성 요소가 비활성화되고 컨트롤이 호출자에게 반환되는 시점에 확인됩니다. 이러한 내용은 기존의 은행 예금 전송 트랜잭션을 보여 주는 그림 5에 설명되어 있습니다.

그림 1.5. 트랜잭션 스트림 및 컨텍스트

트랜잭션의 결과는 루트 개체(이 예에서는 Transfer 개체)가 비활성화되고 클라이언트 메서드 호출이 반환될 때 확인됩니다. 임의의 컨텍스트 내의 일관성 플래그가 False로 설정되었거나 트랜잭션 취소 플래그가 True로 설정된 경우 기본 물리적 DTC 트랜잭션이 취소됩니다.

다음 두 방법 중 하나로 .NET 개체로부터 트랜잭션 결과를 제어할 수 있습니다.

• AutoComplete 특성으로 메서드에 주석을 달고 .NET에서 트랜잭션 결과에 대한 선택 제어를 자동으로 배치합니다. 이 특성을 사용하면 메서드가 예외를 시킬때 일관성 플래그가 자동으로 False로 설정되어 결과적으로 트랜잭션이 취소됩니다. 예외를 발생시지 않고 메서드가 반환되면 일관성 플래그가 True로 설정되어 구성 요소에서 트랜잭션을 커밋해도 된다는 것을 나타냅니다. 이러한 과정은 자동 트랜잭션이 동일 트랜잭션 스트림에서 다른 개체의 선택 사항에 의존하기 때문에 보장되지 않습니다.
• 일관성 플래그를 각각 True 또는 False로 설정하는 ContextUtil 클래스의 정적 SetComplete 또는 SetAbort 메서드를 호출할 수 있습니다.

심각도가 11 이상인 SQL Server 오류가 발생하면 관리 데이터 공급자가 SqlException 유형의 예외가 발생할 수 있습니다. 메서드가 예외를 알리고 처리하는 경우 트랜잭션을 취소하도록 수동으로 선택하거나 [AutoComplete]로 플래깅된 메서드의 경우 예외가 호출자에게 전파되도록 하십시오.

[AutoComplete] 메서드

AutoComplete 특성으로 표시된 메서드의 경우 다음 중 하나를 수행하십시오.

• SqlException을 다시 호출 스택으로 전파합니다.
• 외부 예외에서 SqlException을 래핑하고 이를 호출자에게 전파합니다. 호출자에게 보다 유용한 예외 유형으로 예외를 래핑합니다.

예외를 전파하지 못하면 데이터베이스 오류가 있더라도 개체가 트랜잭션을 취소하도록 선택하지 못할 수 있습니다. 즉, 동일 트랜잭션 스트림을 공유하는 다른 개체에서 수행한 성공적인 작업이 커밋될 수 있습니다.

다음 코드에서는 SqlException을 알리고 이를 호출자에게 직접 전파합니다. 이 개체의 일관성 플래그는 비활성화시에 자동으로 False로 설정되기 때문에 트랜잭션이 결과적으로 취소됩니다.

 [AutoComplete]

void SomeMethod()

{

  try

  {

    // Open the connection, and perform database operation

    . . .

  }

  catch (SqlException sqlex )

  {

    LogException( sqlex ); // Log the exception details

    throw;                 // Rethrow the exception, causing the consistent 

                           // flag to be set to false.

  }

  finally

  {

    // Close the database connection

    . . .

  }

}

  

비-[AutoComplete] 메서드

AutoComplete 특성으로 표시되지 않은 메서드의 경우 다음을 수행해야 합니다.

• catch 블록 내에서 ContextUtil.SetAbort를 호출하여 트랜잭션을 취소하도록 선택합니다. 이렇게 하면 일관성 플래그가 False로 설정됩니다.
• 예외가 발생하지 않는 경우 ContextUtil.SetComplete를 호출하여 트랜잭션을 커밋하도록 선택합니다. 이렇게 하면 일관성 플래그가 True(기본 상태)로 설정됩니다.

다음 코드에서는 이러한 방식에 대해 설명합니다.

void SomeOtherMethod()

{

  try

  {

    // Open the connection, and perform database operation

    . . .

    ContextUtil.SetComplete(); // Manually vote to commit the transaction

  }

  catch (SqlException sqlex)

  {

    LogException( sqlex );   // Log the exception details

    ContextUtil.SetAbort();  // Manually vote to abort the transaction

    // Exception is handled at this point and is not propagated to the caller

  }

  finally

  {

    // Close the database connection

    . . .

  }

}

  

참고  여러 catch 블록이 있는 경우 메서드 시작 시에 ContextUtil.SetAbort를 한 번 호출하고 try 블록의 끝에서 ContextUtil.SetComplete를 호출하는 것이 더 쉽습니다. 이러한 방식에서는 모든 catch 블록 내에서 ContextUtil.SetAbort를 반복해서 호출할 필요가 없습니다. 이러한 메서드로 결정된 일관성 플래그의 설정은 메서드가 반환하는 경우에만 필요합니다

이 방법은 호출 중인 코드에서 트랜잭션이 실패할 것이라는 사실을 인식하도록 만들기 때문에 예외(또는 래핑된 예외)를 호출 스택으로 항상 전파해야 합니다. 이렇게 하면 호출 중인 코드에서 최적화를 수행할 수 있습니다. 예를 들어 은행 예금 전송 시나리오의 경우 전송 구성 요소는 차변 작업이 이미 실패한 경우 대변 작업을 수행하지 않도록 결정할 수 있습니다.

일관성 플래그를 False로 설정한 다음 예외가 발생하지 않고 반환된 경우 호출 중인 코드는 트랜잭션이 실패할 것이라는 사실을 알 수 있는 방법이 없습니다. 부울 값을 반환하거나 부울 출력 매개 변수를 설정할 수 있는 경우에도 일관적으로 예외를 발생시켜 오류 조건을 나타내야 합니다. 이렇게 하면 오류 처리에 대한 표준 방식으로 보다 명확하고 일관적인 코드를 만들 수 있습니다.

형식 'GridView'의 컨트롤 'listIPT'은(는) runat=server 구문과 함께 form 태그 내부에 와야 합니다.

 

    public override void VerifyRenderingInServerForm(Control control)
    {
        // Confirms that an HtmlForm control is rendered for the specified ASP.NET server control at run time.
    }