From: Bill O. <bil...@sa...> - 2009-06-30 18:32:51
|
> Are you absolutely sure that two servers running on different > machines can't both get exclusive locks on the same file on a > shared device? Ann, In my test, worker1 is bb04wrk11. Connecting via ISQL creates this lock file bb04wrk11:/r/sanyo.unx.sas.com/vol/vol10/u101/bioliv> ls -l /tmp/firebird/ total 2064 -rw-rw---- 1 bioliv r&d 0 Jun 30 14:14 fb_init -rw-rw---- 1 bioliv r&d 1048576 Jun 30 14:24 fb_lock_0000016e0000010c00000000017f5615 -rw-rw---- 1 bioliv r&d 1064 Jun 30 14:24 fb_trace -rw-rw---- 1 bioliv r&d 0 Jun 30 14:24 fb_trace_o5aOpZ Worker2 is bb04wrk12. Connecting to same database via ISQL creates this lock file bb04wrk12:/r/sanyo.unx.sas.com/vol/vol10/u101/bioliv> ls -l /tmp/firebird/ total 2064 -rw-rw---- 1 bioliv r&d 0 Jun 30 14:07 fb_init -rw-rw---- 1 bioliv r&d 1048576 Jun 30 14:24 fb_lock_0000016e0000010c00000000017f5615 -rw-rw---- 1 bioliv r&d 1064 Jun 30 14:24 fb_trace -rw-rw---- 1 bioliv r&d 0 Jun 30 14:24 fb_trace_ebaamu Two different lock files + 1 database = trouble. :-) This all makes sense to me... Is likely that a system administrator will set up two servers and try to serve the same data from two different machines? I wouldn't even think to do this, but evidently some some users will try, assuming that fail-over will magically work. Interestingly, fb_lock_print will work on worker1 but fails on worker2. Is this expected, too? bb04wrk11:/r/sanyo.unx.sas.com/vol/vol10/u101/bioliv> fb_lock_print -d mu2.fdb Unable to access lock table. operating system directive shmem_data->sh_mem_length_mapped is 0 failed -Error 0 bb04wrk12:/r/sanyo.unx.sas.com/vol/vol10/u101/bioliv> fb_lock_print -d mu2.fdb LOCK_HEADER BLOCK Version: 145, Active owner: 0, Length: 1048576, Used: 21864 Flags: 0x0001 Enqs: 8, Converts: 0, Rejects: 0, Blocks: 0 Deadlock scans: 0, Deadlocks: 0, Scan interval: 10 Acquires: 14, Acquire blocks: 0, Spin count: 0 Mutex wait: 0.0% Hash slots: 1009, Hash lengths (min/avg/max): 0/ 0/ 3 Remove node: 0, Insert queue: 0, Insert prior: 0 Owners (1): forward: 20840, backward: 20840 Free owners: *empty* Free locks: *empty* Free requests: *empty* Lock Ordering: Enabled OWNER BLOCK 20840 Owner id: 44392781971460, type: 1, pending: 0 Process id: 10336 (Alive), thread id: 1 Flags: 0x00 Requests (7): forward: 20968, backward: 21736 Blocks: *empty* Event log: |