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 <http://opencraft.com> On Saturday, January 24, 2015 at 3:53:04 AM UTC+8, Braden MacDonald wrote: > > 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 > > -- 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.
