Firebird는 Transaction 처리가 기본!!

요즘 Firebird 를 공부하고 있다. 조금은 당황스러운 경험을 하였다.

Firebird 설치시 포함되어 있는 Interactive SQL(isql.exe) 을 이용하여 몇가지 테스트를 하였다. 두 개의 isql 인스턴스를 실행하고 하나의 데이터베이스 연결을 하였다.

A isql 인스턴스(이하 A) 에서 테이블을 하나 생성 하였다. 그리고 B isql 인스턴스(이하 B)에서 데이블이 존재하는지 SHOW TABLE 명령을 확인해 보니 존재 하는 것으로 보였다. 이 것이 DDL은 자동으로 commit 이 되어 그러는 것으로 알았다. 나중에 알게되었지만 DDL 이라도 isql 환경 설정에서 AutoDDL 을 off 로 두면 자동으로 commit 이 수행되지 않는다.

B 에서 방금 생성한 member 테이블에 데이터가 있는지 확인(SELECT * FROM member;)하여 보았다. 데이터가 없음을 확인하고 A 에서 member 테이블에 데이터를 Insert 하고 B 에서 확인을 하였다. B 에서는 아무런 데이터가 확인 되지 않았다. 당연한 결과로 A 에서 작업을 한 후 commit 을 하지 않았기 때문에 B 에서 확인할 수 없었다. A 에서 commit 을 한 후 B 에서 확인을 해 보아도 보이지 않았다. 이상한 일이였다. B 에서 commit 명령을 내리고서야 A 에서 작업한 내용을 확인할 수 있었다.

이 상황이 잘 이해가 되지 않았다. A 에서 작업(Transaction)이 commit 이 되면 B 에서 당연히 확인이 되어야 하는 것으로 생각을 하였다. 이 상황이 잘 못 된 것인줄 알고 MySQL 의 InnoDB 를 이용하여 Transaction 테스트를 해 보았지만 MySQL 는 나의 예상대로 동작을 하였다.

답을 찾아 헤메던 중 외국의 firebird community 에서 도움을 얻어 이유를 알았다. 예전에 오라클을 공부할 때 들었던 관계형 데이터베이스의 ACID 특성에 대해서 다시 듣게 되었다.

B 에서 A 의 작업이 확인되지 않은 이유는 B 에서 데이터를 확인하기 위해 DML(select)을 수행하면서 B 에서 transaction 이 시작 되었고 transaction 이 시작되면서 ACID 의 Isolation 특성으로 데이터베이스는 transaction 이 시작할때의 상태를 독립적으로 유지하게 되어서 B 의 transaction 이 commit 된 후에 A 에서 가한 데이터베이스의 변경된 사항을 확인할 수 있었던 것이였다. mysql 에서도 이러한 관점에서 다시 테스트를 해 보니 동일한 결과를 얻을 수 있었다.

일반적인 GUI 프로그램을 사용하게 되면 Transaction 관리를 하기 때문에 개별적인 작업에 대한 적용이 이루어지는 것이다.

Firebird 란 놈을 좀 더 공부해 보아야겠다. Open Source 정책으로 운영되고 사용자 층이 두텁지 않아서 자료가 많이 부족해서 공부하기가 어렵다.