Given the unknown nature of how the system is deployed readOnly = true can behave in different ways.
For example with amazon aurora and the mariadb driver if you set readOnly = true it will send all the requests to a read
replica endpoint which is subject to lag and inconsistency. There is no serializable isolation level. While the potential
benefits here are nice it is not worth the risk of side effects both within the system codebase itself as modules are replaced
with unknown implementations or to the REST API clients who expect consistent responses (e.g. read after write from HTTP 200 responses).
Removing readOnly = true from all but the non-critical search API's may slow down some performance due to JPA flush and
context evaluation but the consistency gaurantees are likely worth the tradeoff for most of these queries which are point
queries anyway to index backed columns.
Coverage remained the same at 93.788% when pulling 1362fde404702ef21cd7fa66e044ed31f8d68f17 on tgianos:removeMostReadOnly into a30f71c18eb379672553d61d16d00cdb433de79e on Netflix:master.
Given the unknown nature of how the system is deployed
readOnly = true
can behave in different ways.For example with amazon aurora and the mariadb driver if you set
readOnly = true
it will send all the requests to a read replica endpoint which is subject to lag and inconsistency. There is no serializable isolation level. While the potential benefits here are nice it is not worth the risk of side effects both within the system codebase itself as modules are replaced with unknown implementations or to the REST API clients who expect consistent responses (e.g. read after write from HTTP 200 responses).Removing
readOnly = true
from all but the non-critical search API's may slow down some performance due to JPA flush and context evaluation but the consistency gaurantees are likely worth the tradeoff for most of these queries which are point queries anyway to index backed columns.