-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36895/
-----------------------------------------------------------
(Updated Aug. 3, 2015, 2:39 p.m.)
Review request for Ambari, Alejandro Fernandez, Nate Cole, and Sumit Mohanty.
Changes
-------
Bitten by SQL Azure again. They don't support tables without CLUSTERED indexes:
```
Exception [EclipseLink-4002] (Eclipse Persistence Services -
2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: com.microsoft.sqlserver.jdbc.SQLServerException: Tables
without a clustered index are not supported in this version of SQL Server.
Please
create a clustered index and try again.
Error Code: 40054
```
It seems like the original problem boils down to how SQL Server applies the
predicate values in its search. It performs 2 b-tree seeks; the first one on
only the cluster_id and the second on the rest. This means that instead of
hashing the values and going directly to a row lock, it must perform an X->U
lock since it's doing a scan of the whole table.
The solution was to move away from the compound, clustered PK and rely solely
on a surrogate unique ID.
Bugs: AMBARI-12570
https://issues.apache.org/jira/browse/AMBARI-12570
Repository: ambari
Description
-------
Similar to AMBARI-12526, Ambari installation via a blueprint on SQL Azure gets
stuck somewhere between 90% and 100% because of a SQL Database deadlock.
- We have dual X-locks on hostcomponentstate asking for U-locks when updating
the CLUSTERED INDEX.
- Both dual X-locks, from different transactions and different processes, are
on the same row (technically impossible) - based on the XML execution plan, we
can see that the concurrent UPDATE statements are executing on different rows
due to their CLUSTERED INDEX predicate.
- In Java, Ambari has locks which prevent concurrent U- or X-locks on the same
row
- Only happens on SQL Server
My best suspicion right now is that we have a key hash collision happening on
this table. That's why two processes appear to have the same lock even though
they are on different rows.
Restricting row-level locking on this table will prevent locking on hash keys
which could collide.
Diffs (updated)
-----
ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostComponentStateDAO.java
fb585fd
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentStateEntity.java
45e036b
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentStateEntityPK.java
86e0dee
ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java
0850a79
ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql 1b67b24
ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql 16f6a0a
ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql cd6e27a
ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql
c7138be
ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 0ff1aff
ambari-server/src/test/java/org/apache/ambari/server/state/ServiceComponentTest.java
96bbb1d
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClustersTest.java
ce1fd34
ambari-server/src/test/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostTest.java
f6ab0ec
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog170Test.java
93f7f8c
ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog200Test.java
484c18d
Diff: https://reviews.apache.org/r/36895/diff/
Testing
-------
Deployed a clean cluster on SQL Server and then ran 10+ deployments on SQL
Azure without seeing a deadlock.
Thanks,
Jonathan Hurley
