<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 24 25  
26 27 28 29 30 31
00:30 glennpratt joined
01:40 filterfish_ joined
01:40 filterfish_ left
03:17 ta_ joined
04:35 glennpratt joined
04:43 ta_ joined
05:06 jeremyevans joined
05:37 glennpratt joined
05:48 ta_ joined
06:11 Takumo joined
06:11 Takumo joined
07:00 ta_ joined
07:46 glennpratt joined
08:16 ta_ joined
10:04 ta_ joined
11:03 ta_ joined
12:09 haennar joined
12:22 ta_ joined
13:04 ta_ joined
15:08 haennar joined
19:26 jeremyevans joined
19:27 jeremyevans joined
21:08 A124 joined
21:14 foxxx0 joined
21:18 tercenya_ joined
23:29 scratchcat joined
23:32 <scratchcat> I'm acquiring pessimistic locks (FOR UPDATE NOWAIT) for my application (using sequel db.fetch( <sql code> ) and im writing a test case to verify that a concurrent transaction should fail with error LockNotAvailable. However, for some reason, in one test case (via rspec) the concurrent command to acquire the same lock does not fail. However, if I access the database via psql and do the exact same command, it does fail with that error.
23:33 <scratchcat> I've also tried it via model.lock or model.for_update etc
23:35 <scratchcat> (also using forkbreak)
23:47 <scratchcat> Hmm, so a question. For sequel transactions, if a transaction attempts to acquire a lock via (update no wait), does it actually conflict with anotther transaction (that has yet to be committed) that acquires the same lock? My assumption was that the error would be thrown, but if thats not the case (e.g. the commands in the transaction are not evaluated till later [ optimistic concurrency ]), then its just that my test case has the wr