Moodle
  1. Moodle
  2. MDL-23273

limit of responses at module choice fail at synchronous submissions

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.9.5, 2.7
    • Fix Version/s: 2.0.10, FRONTEND
    • Component/s: Choice
    • Labels:
    • Affected Branches:
      MOODLE_19_STABLE, MOODLE_27_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE
    • Rank (Obsolete):
      496

      Description

      To reproduce the bug:
      1.create a new course or use an existing one
      2.add item 'choice' with defaults values excpet the following settings:

      Limit the number of responses allowed = enable
      some choices where limit = 1
      Restrict answering to this time period = yes
      Display vertically
      Publish results = always show results to students
      privacy of results = publish full results, showing names and their choices
      group mode = separate groups

      3.login at 2 different PCs with different student account
      4.select same choice and hit 'save my choice' synchronously

      As you can see in the attachment, choosing a limited choice is possible. We have received some complaints by teachers using this tool. They report that (somehow) this effect happens quite often, especially when tight time period is enabled.

      Thank you for your help in advance!!!

        Issue Links

          Activity

          Hide
          Dan Marsden added a comment -

          Unfortunately there isn't much we can do about this for 1.9Stable, but we can use the transaction support in 2.0 to improve this a bit (only for databases that support transactions) - It's important to note that MySQL MyIsam tables don't support transactions.

          I'll look at adding transaction support to to 2.01 (unless I get to it earlier.)

          Show
          Dan Marsden added a comment - Unfortunately there isn't much we can do about this for 1.9Stable, but we can use the transaction support in 2.0 to improve this a bit (only for databases that support transactions) - It's important to note that MySQL MyIsam tables don't support transactions. I'll look at adding transaction support to to 2.01 (unless I get to it earlier.)
          Hide
          Gergely Rakoczi added a comment -

          Dear Dan,
          thank you for your helpful information! As a consequence we're waiting for Moodle 2.01.

          Show
          Gergely Rakoczi added a comment - Dear Dan, thank you for your helpful information! As a consequence we're waiting for Moodle 2.01.
          Hide
          Andrea Bicciolo added a comment -

          Hi Dan,

          it appears to me that a similar issue happens also when Limit=1 for most (or all choice) even without synchronous submissions.

          Logs report two student able to select the seam choice (limited at 1) in two different days. In this case transaction support should not be necessary. Maybe it could worth taking a look: Dan I can provide cases if you want to further explore.

          Show
          Andrea Bicciolo added a comment - Hi Dan, it appears to me that a similar issue happens also when Limit=1 for most (or all choice) even without synchronous submissions. Logs report two student able to select the seam choice (limited at 1) in two different days. In this case transaction support should not be necessary. Maybe it could worth taking a look: Dan I can provide cases if you want to further explore.
          Hide
          David Campbell added a comment -

          I posted this also in the choice module forum.

          I just used the choice activity to have students preregister for 7 courses. There were a variety of limits for the different sections, but in some cases the number of students exceeded the set limt. For example, I set a 20 person limit for the Monday 2nd period section, but 29 were able to select that section. This only happened to 3 other sections and they were ones with higher limits. I don't know if this had anything to do with it, but the server was hit pretty hard. When the activity opened there about 300 users trying to make selections and the server really slowed down. A couple of students that I know of also got database errors. None of the students unenroled during that time, but they were able update their choices.

          Show
          David Campbell added a comment - I posted this also in the choice module forum. I just used the choice activity to have students preregister for 7 courses. There were a variety of limits for the different sections, but in some cases the number of students exceeded the set limt. For example, I set a 20 person limit for the Monday 2nd period section, but 29 were able to select that section. This only happened to 3 other sections and they were ones with higher limits. I don't know if this had anything to do with it, but the server was hit pretty hard. When the activity opened there about 300 users trying to make selections and the server really slowed down. A couple of students that I know of also got database errors. None of the students unenroled during that time, but they were able update their choices.
          Hide
          Claus A. Us. added a comment -

          First of all, this problem occurs in version 2.5.2 as well.
          We had courses with 500 students who tried to use choice module as first come first serve distribution of courses. The choices were timed, thus most of the students visited our page at the same time. (We do not recommend this module for large courses because of the heavy server load generated when students try to access the module, but we cannot prevent teachers from using it in these situations.)
          We recognized a further unwanted behaviour: some students even were able to choose an option twice or even three times. If this happens, the limit of that option can never be reached (under usual conditions), because the option is closed since the user is counted twice. Nevertheless the overview does not list the user twice, that list shows a distinct list. Thus, if the limit is 30 the list shows 29 users and on the same time no other user can choose that option as it is marked as closed.
          I suppose using transaction leads to problems with exceeding the connection pool, and thus lead to database connection errors. Maybe a solution would be a double check, a second check, that checks if limit is exceeded and the choice is revoked.

          Show
          Claus A. Us. added a comment - First of all, this problem occurs in version 2.5.2 as well. We had courses with 500 students who tried to use choice module as first come first serve distribution of courses. The choices were timed, thus most of the students visited our page at the same time. (We do not recommend this module for large courses because of the heavy server load generated when students try to access the module, but we cannot prevent teachers from using it in these situations.) We recognized a further unwanted behaviour: some students even were able to choose an option twice or even three times. If this happens, the limit of that option can never be reached (under usual conditions), because the option is closed since the user is counted twice. Nevertheless the overview does not list the user twice, that list shows a distinct list. Thus, if the limit is 30 the list shows 29 users and on the same time no other user can choose that option as it is marked as closed. I suppose using transaction leads to problems with exceeding the connection pool, and thus lead to database connection errors. Maybe a solution would be a double check, a second check, that checks if limit is exceeded and the choice is revoked.
          Hide
          jose antonio rodriguez added a comment -

          Hi,
          We have noticed that when we set up the choice with the option NO GROUPS, then it works correctly.

          Show
          jose antonio rodriguez added a comment - Hi, We have noticed that when we set up the choice with the option NO GROUPS, then it works correctly.
          Hide
          Monash University VLE team added a comment -

          Occurring in 2.3.2 and 2.5.5 at the moment.

          Show
          Monash University VLE team added a comment - Occurring in 2.3.2 and 2.5.5 at the moment.
          Hide
          Claus A. Us. added a comment -

          Dear Jose,
          It should not be a difference whether you enable group mode or not. Your tests were not good enough. Under high load conditions there will still be an overbooking.
          Hi all,
          I added a diff with changes I made to overcome the problem. The fix solves the issue of overbooking by double-checking if the limit is reached after the choice is saved to the database. In case of overbooking the choice is deleted again. This is not best practice coding since using transactions would be the way of choice, but this approach seems reasonable. This fix is in use since March. The limits did not exceeded till then although we had some choices causing high load.
          Nevertheless with that fix there is a limitation or maybe a bug fix for another problem This diff file changes the behaviour of the module a bit:
          Usually the choice module did not include choices of unenrolled students for calculating the number of submitted choices. It was possible that someone has chosen an option and afterwards the limit was reached. This person can then unenrol form course and another student is able to choose that option. After enrolling again, the choice of the former unenrolled student is considered again for the calculation the limit and thus the limit is exceeded. The result now lists unenrolled choices as well, but instead of printing the username an “unenrolled” entry is added. It can be deleted by the teacher.

          Show
          Claus A. Us. added a comment - Dear Jose, It should not be a difference whether you enable group mode or not. Your tests were not good enough. Under high load conditions there will still be an overbooking. Hi all, I added a diff with changes I made to overcome the problem. The fix solves the issue of overbooking by double-checking if the limit is reached after the choice is saved to the database. In case of overbooking the choice is deleted again. This is not best practice coding since using transactions would be the way of choice, but this approach seems reasonable. This fix is in use since March. The limits did not exceeded till then although we had some choices causing high load. Nevertheless with that fix there is a limitation or maybe a bug fix for another problem This diff file changes the behaviour of the module a bit: Usually the choice module did not include choices of unenrolled students for calculating the number of submitted choices. It was possible that someone has chosen an option and afterwards the limit was reached. This person can then unenrol form course and another student is able to choose that option. After enrolling again, the choice of the former unenrolled student is considered again for the calculation the limit and thus the limit is exceeded. The result now lists unenrolled choices as well, but instead of printing the username an “unenrolled” entry is added. It can be deleted by the teacher.
          Hide
          Claus A. Us. added a comment -

          Moodle 2.6:
          Changes:

          • prevents overbooking by double checking limit after inserting choice to DB
          • considers unenrolled students for limit
          • enables deletion of unenrolled choices by teacher
          Show
          Claus A. Us. added a comment - Moodle 2.6: Changes: prevents overbooking by double checking limit after inserting choice to DB considers unenrolled students for limit enables deletion of unenrolled choices by teacher
          Hide
          Dan Marsden added a comment -

          Thanks Claus - looks like some interesting code there.

          No existing Modules show enrolled and un-enrolled user data to teachers that I know of but we have to deal with the issue where course data is kept for a user when un-enrolled and this causes problems for the choice limit if they re-enrol again. I still haven't worked out the best way to handle un-enrolled user data but I'm open to ideas (and patches!)

          The double checking of the limit is something that I'm sure the code used to do (pre Moodle 2) but someone refactored that at some point and it was lost

          Show
          Dan Marsden added a comment - Thanks Claus - looks like some interesting code there. No existing Modules show enrolled and un-enrolled user data to teachers that I know of but we have to deal with the issue where course data is kept for a user when un-enrolled and this causes problems for the choice limit if they re-enrol again. I still haven't worked out the best way to handle un-enrolled user data but I'm open to ideas (and patches!) The double checking of the limit is something that I'm sure the code used to do (pre Moodle 2) but someone refactored that at some point and it was lost
          Hide
          Dan Marsden added a comment -

          unassigning myself from this issue so that someone else can pick it up if they want to but I'll still keep an eye on comments/patches etc

          Show
          Dan Marsden added a comment - unassigning myself from this issue so that someone else can pick it up if they want to but I'll still keep an eye on comments/patches etc
          Hide
          Paul Holden added a comment -

          MDL-12083 deals with removing user choice submissions when the user is unenrolled from a course; this would prevent one of the causes of choice limits being exceeded

          Show
          Paul Holden added a comment - MDL-12083 deals with removing user choice submissions when the user is unenrolled from a course; this would prevent one of the causes of choice limits being exceeded

            People

            • Votes:
              5 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated: