기본적으로는 lock level 에 따라서 commit/rollback 을 통한 transaction 정리가 필요해집니다. 일반적으로 DB에 write 행위가 일어났을 때는 반드시 transaction 정리를 해주어야 하며, read 행위 시에도 lock 이 발생하는 lock level 을(REPEATABLE READ 이상) 일 경우에도 transaction 을 정리해 주어야 합니다.
지금 질문하신 경우는 JDBC/ODBC/PHP 등을 사용하는 경우를 말씀하시는 것으로 보이며, 저희 제품은 구조상 3-tier 형태를 취하고 있습니다. 즉 driver 가 바로 DB server로 접근하는 것이 아니라 중간에 Broker라는 미들웨어 를 두어 Broker 의 CAS 에서 connection 관리 등을 통한 서비스를 하고 있습니다.
문제는 CAS 의 숫자를 무한정으로 할 수가 없으므로 어느 정도 제한된 숫자로 서비스를 하다 보니 어느 한 driver 가 오랫동안 한 CAS를 점유(한 transaction 동안)하게 되면 다른 driver 들이 서비스를 받을 기회가 적어진다는 것입니다.
현재 select 만을 수행하더라도 transaction 의 시작으로 간주하기 때문에 한 개의 CAS 가 한 개의 driver 에 점유되어 버립니다.
따라서 일반적은 상황에서는 auto commit 을 on으로 하시고, insert/update/delete 의 상황에서만 auto commit 을 off로 하신 후 commit/rollback 처리를 하시면 됩니다.
만약 auto commit 이 제공되지 않는다면 불편하시더라도 select 사용 후 바로 commit 을 하도록 하셔야 합니다.
지금 질문하신 경우는 JDBC/ODBC/PHP 등을 사용하는 경우를 말씀하시는 것으로 보이며, 저희 제품은 구조상 3-tier 형태를 취하고 있습니다. 즉 driver 가 바로 DB server로 접근하는 것이 아니라 중간에 Broker라는 미들웨어 를 두어 Broker 의 CAS 에서 connection 관리 등을 통한 서비스를 하고 있습니다.
문제는 CAS 의 숫자를 무한정으로 할 수가 없으므로 어느 정도 제한된 숫자로 서비스를 하다 보니 어느 한 driver 가 오랫동안 한 CAS를 점유(한 transaction 동안)하게 되면 다른 driver 들이 서비스를 받을 기회가 적어진다는 것입니다.
현재 select 만을 수행하더라도 transaction 의 시작으로 간주하기 때문에 한 개의 CAS 가 한 개의 driver 에 점유되어 버립니다.
따라서 일반적은 상황에서는 auto commit 을 on으로 하시고, insert/update/delete 의 상황에서만 auto commit 을 off로 하신 후 commit/rollback 처리를 하시면 됩니다.
만약 auto commit 이 제공되지 않는다면 불편하시더라도 select 사용 후 바로 commit 을 하도록 하셔야 합니다.