XBlock Scope.user_state_summary locking?

[Braden MacDonald]

The XBlock API defines Scope.user_state_summary fields which allow sharing data among the students who use an XBlock. Is there any guarantee that XBlock's can use those fields without read-write conflicts?

For example, look at the "thumbs" sample XBlock: https://github.com/edx/xblock-sdk/blob/master/sample_xblocks/thumbs/thumbs.py

If two users vote at the exact same time, and their requests are (say) served by different gunicorn processes, is it possible that both blocks will read the value of "upvotes" at the same time, increment it by one, and then save their changes, so the second overwrites the first and only one upvote gets recorded?

I wasn't able to tell with a cursory look through the code. It seems that for the LMS runtime, the FieldDataCache has a select_for_update option but it's usually turned off. There is a potential workaround posted here previously at  https://groups.google.com/d/msg/edx-code/2a87zxjlrX0/xvqtvxCz8lwJ which seems like it would help but it seems to me that it doesn't go far enough...

Thanks!

--

Braden MacDonald

@OpenCraft

[Calen Pennington]

There isn't any explicit locking. The expectation is that that data is aggregate, and that a some undercounting is ok (such as in the thumbs example).

-Cale

[eug...@opencraft.com]

Hi guys!

Sorry for necro-posting, but that's exactly the right thread to discuss it:

• Is this still the case (i.e. no locking for user_state_summary)? As far as I can tell it is, but just to make sure.
• If so, would it be a good thing if we develop such a mechanism as an opt-in option for XBlock/XModule authors to use?

Regards,

Eugeny
@Opencraft

[David Ormsbee]

Hi folks,

[Fair disclaimer: I'm not a fan of this scope existing in the first place. We do need better solutions for sharing data across students for the same piece of content. But that's a deeper rabbit hole.]

It is still the case that there is no locking around user_state_summary.

I would strongly caution against making a locking mechanism for it. It is really easy to get tripped up when things start getting busy. Rendering the courseware index can be very slow, meaning that you might be holding that lock for a second or more for a single transaction. You could get into deadlock situations where there are two problems with separate locks, and two users each have one of those locks and is waiting on the other before they can complete their transaction (and causing a pile on for everyone else). You'll also run into bugs caused by the transaction isolation mode the database is set in.

Locking the row can also bite you in really unexpected ways. One of the reasons select_for_update is no longer used for FieldDataCache is that we once had an issue where running a grading task would lock the associated users, preventing an entire course from logging in while it was being graded (logging in updates a user's last_login).

At the end of the day, it can be done. But I believe doing it in a sane way is a lot trickier than it appears to be at first glance.

Do you mind detailing the specific use case?

Take care.

Dave

--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/712f6670-1c92-4e04-b964-50ddeb394584%40googlegroups.com.