-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36561/#review91990
-----------------------------------------------------------



src/main/java/org/apache/aurora/scheduler/storage/db/DbModule.java (line 120)
<https://reviews.apache.org/r/36561/#comment145782>

    Can this be sent to slf4j instead? From 
http://www.h2database.com/html/features.html#trace_options it looks like this 
can be done with TRACE_LEVEL_FILE=4



src/main/java/org/apache/aurora/scheduler/storage/db/RowGarbageCollector.java 
(line 92)
<https://reviews.apache.org/r/36561/#comment145788>

    `deletedCount.get()`
    
    Or just move `deletedCount` and this log statement into the work block


- Kevin Sweeney


On July 16, 2015, 4:44 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:44 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
> 
>

Reply via email to