Make XBlock views/handlers non-atomic requests.#23559
Conversation
|
@cpennington, @davestgermain, @stvstnfrd: First cut at this is the dumb thing -- just relaxing atomic requests for XBlock callbacks and the main courseware rendering. |
ormsbee
force-pushed
the
ormsbee/csm_write_optimization
branch
from
8f2e19f to
6d4700c
Compare
|
That's aggressive. Do we want to add some lower level transactions? |
|
@cpennington: User state writes are already wrapped in a transaction. In most cases, CSM are the only writes in these transactions. ORA2 does its own transaction handling as well. Are there particular areas you think I should wrap? Or should I start with a more conservative change (say, only the courseware index view)? |
We're seeing slow commits on production for courseware_studentmodule updates. Based on the slow queries during those times, we think it might be because multiple worker processes are trying to update the same rows from within long-running transactions (since courseware is relatively slow). The risk with this is that since the whole view execution is no longer wrapped in a big implicit transaction, it's possible that XBlock state will update and things that key off of that (e.g. completion progress information or pre-req milestones) will fail in a way that will leave the database in an unplanned-for state, though this is already the case for those actions that trigger asynchronous tasks like grades recalculation. The query counts for the index view test were adjusted down because save points count towards the total and we're no longer setting them at the top level around the view as a whole.
ormsbee
force-pushed
the
ormsbee/csm_write_optimization
branch
from
6d4700c to
5ea71be
Compare
|
Your PR has finished running tests. There were no failures. |
|
FYI @abutterworth, @davidjoy |
|
EdX Release Notice: This PR has been deployed to the staging environment in preparation for a release to production. |
|
EdX Release Notice: This PR has been deployed to the production environment. |
4 participants
We're seeing slow commits on production for courseware_studentmodule
updates. Based on the slow queries during those times, we think it
might be because multiple worker processes are trying to update the
same rows from within long-running transactions (since courseware
is relatively slow).
The risk with this is that since the whole view execution is no
longer wrapped in a big implicit transaction, it's possible that
XBlock state will update and things that key off of that (e.g.
completion progress information or pre-req milestones) will fail
in a way that will leave the database in an unplanned-for state,
though this is already the case for those actions that trigger
asynchronous tasks like grades recalculation.