- Berkeley DB Reference Guide:
- Locking Subsystem
|
|
If an application runs with locking specified, but not transactions (for example, DB_ENV->open is called with DB_INIT_LOCK or DB_INIT_CDB specified, but not DB_INIT_TXN), locks are normally acquired during each Berkeley DB operation and released before the operation returns to the caller. The only exception is in the case of cursor operations. Cursors identify a particular position in a file. For this reason, cursors must retain read locks across cursor calls to make sure that the position is uniquely identifiable during a subsequent cursor call, and so that an operation using DB_CURRENT will always refer to the same record as a previous cursor call. These cursor locks cannot be released until the cursor is either repositioned and a new cursor lock established (for example, using the DB_NEXT or DB_SET flags), or the cursor is closed. As a result, application writers are encouraged to close cursors as soon as possible.
(만약 애플리케이션에 락설정이 있고 트랙젝션이 없을때( DB_ENV->open 이 DB_INIT_TXN없이 DB_INIT_LOCK or DB_INIT_CDB로 설정되어 호출때 ),락은 보통 버클리디비 오퍼레이션중에 얻어지고 호출자에게 리턴되기 전에 놓여진다.이경우 유일한 예외는 커서오퍼레이션의 경우다.커서는 파일의 특정한 위치를 인식한다.이와같은 이유로 커서는 커서콜중에 포지션이 유일성있게 식별되어야 하고 이것을 통해 DB_CURRENT를 사용하는 오퍼레이션은 항상 이전의 커서콜때와 같은 레코드를 참조해야 되기때문에 커서콜사이에서 읽기락이 걸려야 한다.이 커서락은 커서의 리포지셔닝, 새로운커서락이 성립(DB_NEXT or DB_SET flags)중의 한가지가 설정되거나 커서를 닫기 전까지는 릴리즈되지 않는다.결과적으로 애플리케이션은 커서를 가능한 빨리 닫아야 한다.
It is important to realize that concurrent applications that use locking must ensure that two concurrent threads do not block each other. However, because Btree and Hash access method page splits can occur at any time, there is virtually no way to guarantee that an application that writes the database cannot deadlock. Applications running without the protection of transactions may deadlock, and can leave the database in an inconsistent state when they do so. Applications that need concurrent access, but not transactions, are more safely implemented using the Berkeley DB Concurrent Data Store Product.
(락을 사용하는 동시성있는 애플리케이션은 반드시 두개의 쓰래드가 서로를 블락시키지 않도록 하는것이 중요하다.그러나 Btree 와 Hash엑세스 메소드 페이지 분할은 어떠한 순간에도 일어날 수 있기 때문에 가상적으로 데드락을 벗어날수 있는 방법은 없다.트랜젝션의 보호없이 동작하는 애플리케이션은 데드락 될 수 있다.그리고 데드락이 걸리면 불일치상태로 디비를 떠날수 있다. 트랜젝션업싱 동시접근을 원하는 애플리케이션은 Berkeley DB Concurrent Data Store Product를 사용하여 좀더 안정성있게 구현된다.)
|
|
Copyright (c) 1996-2003 Sleepycat Software, Inc. - All rights reserved.