2011-04-05 9 views
0

다른 응용 프로그램에 대한 성능 데이터를 저장하는 여러 데이터베이스에서 동시에 트랜잭션을 처리하는 Python 서버에서 작업하고 있습니다. 동시 처리는 다중 처리 모듈을 통해 이루어 지므로 각 트랜잭션 스레드는 새로운 프로세스에서 시작되고 공유 메모리 데이터 보호 체계는 실행 가능하지 않습니다. DBMS로 sqlite를 사용하고 있으며 각 응용 프로그램의 DB를 자체 파일로 설정하기로했습니다. 불행히도, 이것은 DB 생성에 경쟁 조건을 도입합니다. 두 프로세스가 동일한 새 응용 프로그램에 대한 DB를 동시에 만들려고하면 둘 다 DB를 저장할 파일을 만듭니다. 내 연구에 따르면 파일을 생성하기 전에 파일을 잠글 수 없다는 믿음이 생깁니다. 파일이 생성되지 않고 동시에 쓰여지는 것을 보장하기 위해 사용할 수있는 다른 메커니즘이 있습니까? 사전에파이썬에서 파일 생성 금지.

감사합니다, 그들이 충돌하지 보장되는 방식으로 데이비드

+0

어쩌면 내가 오해 해요,하지만 당신은 단지 각 DB의 파일 위치를 이름을 바꿀 수 없습니다 : 사용자의 필요에 따라, 어쩌면 파이썬 바인딩을 제공하는 다시 구현 알고리즘을 단지에 유용한, 또는 것? – dfb

답변

1

일반적인 파일에 대해이를 처리하는 일반적인 유닉스 스타일의 방법은 파일을 만들고 실패하는지 확인하는 것입니다. 파이썬의 경우, 그것은 다음과 같습니다

try: 
    os.open(filename, os.O_WRONLY | os.O_CREAT | os.O_EXCL) 
except IOError: # or OSError? 
    # Someone else created it already. 

적어도, 당신은 데이터베이스에 비슷한 이름의 "잠금 파일"을 만들려고하는이 방법을 사용할 수 있습니다. 잠금 파일이 작성되면, 데이터베이스를 작성하십시오. 그렇지 않다면, 당신은 "데이터베이스 존재"의 경우에 당신이 필요로하는 것을하십시오.

0

이름 데이터베이스 파일. 당신의 코드와 예외 핸들러에서 파일을 작성하는 파일이 존재하는지 확인하고 대신를 만드는 기존 파일을 사용하려고 할 때

http://docs.python.org/library/tempfile.html

0

당신은 오류를 캡처 할 수 있습니다.

0

플랫폼에 대해서는 언급하지 않았지만 리눅스에서는 open() 또는 os.open() (Python에서는) 사용할 수있는 flags 매개 변수를 사용합니다. 파일이 존재하지 않으면 O_CREAT 플래그가 파일을 생성하고 파일이 이미 존재하면 O_EXCL 플래그가 오류를 발생시킵니다. 액세스 모드를 지정하려면 O_RDONLY, O_WRONLY 또는 O_RDWR이 필요합니다. 이 상수는 os 모듈에서 찾을 수 있습니다. 예를 들어

: fd = os.open(filename, os.O_RDWR | os.O_CREAT | os.O_EXCL)

0

당신은 단지 하나의 프로세스가 파일 때문에 데이터베이스를 얻을 수 있음을 보장하기 위해 POSIX O_EXCL and O_CREAT flags to open(2)을 사용할 수 있습니다; O_EXCL은 NFSv2 또는 이전 버전에서 작동하지 않으며 다른 네트워크 파일 시스템에 의존하는 것이 매우 불안정합니다.

liblockfile 라이브러리는 open(2) 맨 페이지에 설명 된 네트워크 파일 시스템 안전 잠금 메커니즘을 구현하는데 편리합니다. 하지만 미리 만든 Ruby와 Perl 바인딩 만 볼 수 있습니다.

O_EXCL Ensure that this call creates the file: if this flag is 
      specified in conjunction with O_CREAT, and pathname 
      already exists, then open() will fail. The behavior of 
      O_EXCL is undefined if O_CREAT is not specified. 

      When these two flags are specified, symbolic links are not 
      followed: if pathname is a symbolic link, then open() 
      fails regardless of where the symbolic link points to. 

      O_EXCL is only supported on NFS when using NFSv3 or later 
      on kernel 2.6 or later. In environments where NFS O_EXCL 
      support is not provided, programs that rely on it for 
      performing locking tasks will contain a race condition. 
      Portable programs that want to perform atomic file locking 
      using a lockfile, and need to avoid reliance on NFS 
      support for O_EXCL, can create a unique file on the same 
      file system (e.g., incorporating hostname and PID), and 
      use link(2) to make a link to the lockfile. If link(2) 
      returns 0, the lock is successful. Otherwise, use stat(2) 
      on the unique file to check if its link count has 
      increased to 2, in which case the lock is also successful.