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
    • Fix Version/s: 2.0.10
    • Component/s: Choice
    • Labels:
      None
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE
    • Rank:
      445

      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!!!

        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.

          People

          • Votes:
            4 Vote for this issue
            Watchers:
            11 Start watching this issue

            Dates

            • Created:
              Updated: