----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/36561/#review91995 -----------------------------------------------------------
Ship it! Ship It! - Kevin Sweeney On July 16, 2015, 4:59 p.m., Bill Farner wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/36561/ > ----------------------------------------------------------- > > (Updated July 16, 2015, 4:59 p.m.) > > > Review request for Aurora and Kevin Sweeney. > > > Bugs: AURORA-1401 > https://issues.apache.org/jira/browse/AURORA-1401 > > > Repository: aurora > > > Description > ------- > > Use the application-level storage lock to prevent DB-level deadlock when > GCing rows. > > > Diffs > ----- > > src/main/java/org/apache/aurora/scheduler/storage/db/DbModule.java > 0b76caf717b6b7c36fcbbd41eb2adcac0cc0736b > > src/main/java/org/apache/aurora/scheduler/storage/db/RowGarbageCollector.java > ba7c677039270a1e1b413b50ee7091697ea543a6 > src/test/java/org/apache/aurora/scheduler/app/local/LocalSchedulerMain.java > 1597725ef67b98fb48569c0c3f36bea502ec6daf > > Diff: https://reviews.apache.org/r/36561/diff/ > > > Testing > ------- > > Tried to explore options for repeatably reproducing this in a test case, but > came up with nothing. With the lock mode we currently use (READ > UNCOMMITTED), i believe there is no way to acquire a lock and hold it after a > statement finishes executing. This means that only joins are susceptible to > deadlock, which would be ~impossible to reproduce repeatably. > > > Thanks, > > Bill Farner > >
