MongoStatement.getUpdateCount derives the update count for an update command from BulkWriteResult.getModifiedCount(). JDBC's contract for java.sql.Statement#executeUpdate is the DML row count, which by convention means rows MATCHED, not rows whose values changed: MySQL's Connector/J documents useAffectedRows=true as the deviation from JDBC compliance, PostgreSQL reports matched rows, and Hibernate's Expectation.RowCount machinery assumes matched semantics.

Reproduction: seed two documents where one already holds the target value, then run a bulk HQL update matching both, e.g. update Book set outOfStock = true where one of the two matched books already has outOfStock = true. MutationQuery.executeUpdate (a direct pass-through of the JDBC count via StandardJdbcMutationExecutor) returns 1; the JDBC-correct answer is 2.

Fix: derive the count from getMatchedCount(). The regression test is the reproduction above with an exact-count assertion.

Found while implementing HIBERNATE-217, where the same formula made a matched-but-unmodified upsert report 0 and Hibernate converted that into StaleObjectStateException; the upsert-side counting lands with HIBERNATE-217 on top of this fix.