----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/34821/#review85780 -----------------------------------------------------------
Ship it! Ship It! - Robert Nettleton On May 29, 2015, 7 p.m., John Speidel wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/34821/ > ----------------------------------------------------------- > > (Updated May 29, 2015, 7 p.m.) > > > Review request for Ambari, Robert Nettleton, Sumit Mohanty, Sid Wagle, and > Tom Beerbower. > > > Bugs: AMBARI-11542 > https://issues.apache.org/jira/browse/AMBARI-11542 > > > Repository: ambari > > > Description > ------- > > When provisioning a cluster via the blueprint api, occasionally a database > deadlock is detected. There is retry logic around this code so it doesn't > affect the creation of the cluster and a user wouldn't notice this unless > they looked at the logs. That being said, this issue involves incorrect > transaction demarcation and synchronization and is potentially serious > depending on how it is manifested. > > The fix involves changing the scope of the database transaction as well as > synchronization. > There are currently many issues transaction/synchronization issues in the > state layer that need to be addresses, this only deals with this exact use > case. > > Also, this patch strictly deals with correctness and I didn't make an effort > to optimize this path. If this results is a performance regression, there > are several approaches that we could take. > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java > 792b6fe > > Diff: https://reviews.apache.org/r/34821/diff/ > > > Testing > ------- > > Provison clusters many times via looking for a reported database deadlock. > Without this patch, I was able to reproduce the deadlock fairly consistently > and with the patch no deadlock occurred across many installs. > > Unit Tests: > - tx/synchronization change only so no new unit test > - currently running full unit test suite and will update review with result > summary when completed > > > Thanks, > > John Speidel > >
