LMSCommit... what does it do?


I received this question from a customer today:

Is there a mechanism for content to force the Scorm API Adapter to send data back to the LMS without calling LMSFinish()?  We did find a reference to LMSCommit() on the web but wanted to confirm with you that this would work.

Well, it sure sounds like that's the right answer, doesn't it?  Contextually, it's important to understand that this question comes from one of our SCORM Engine customers (LMS side of things). 

Technically, according to the standard, the LMS's behavior isn't substantially impacted by the call of LMSCommit.  (LMSCommit, in particular, as part of SCORM 1.2, has little effect.  In the SCORM Engine, when Commit (the SCORM 2004 comparable) is called, we invoke our look ahead sequencer, which might change the available links in the course menu.  But that's SCORM 2004 only.)

Some LMS's are more substantially impacted though.  Some wait for a call to LMSCommit to actually push data to the server.  Others won't ever persist data unless that call is made. 


In the SCORM Engine, the decision about when to send data from the browser to the server is governed entirely by the commit frequency set in the SCORM package properties.  This invokes a method that assesses if there's any dirty data, and if it finds any, pushes it to the server.






Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request


  • Avatar
    Chris Bobbitt



    We currently have SCORM 2004 compliant packages that one store data to the engine's LMS database when an LMSFinish is invoked.  If the user's connectivity is interrupted, then course progress can be lost.  We'd like the packages to perform an LMSCommit when the user exits each screen, theoretically persisting any progress to this point.  The question is, in fact will that do that, and is any serious performance issues going to result?


    Chris Bobbitt

  • Avatar
    John Mensel

    It depends a lot on the LMS you're using.  From a technical read of the standard, we believe that the LMS is obligated to persist any SetValue's prior to the Commit call anyway.  So, again from our perspective, the Commit call is irrelevant.

    Now, other LMSs will probably interpret that differently.  They might wait for Commit or Terminate prior to doing something with the data.  In those cases, you might be helping yourself.

    It's tough to tell from here, but is your content waiting until the last page to even make its SetValue calls?  In that case, the Commit calls wouldn't help at all.

  • Avatar
    Mark Statkus

    This question has come up for us as well several times.  Reading ADL's documentation it seems like they left it open to interpretation which added some obvious questions about what a "data store" is and what a cached or uncached session is.

    Right now if I think about HTTP posts I'd be concerned about them getting out of order.  Meaning, if the SCO calls Commit(""), then the LMS fires up a HTTP post to the backend to store the data that communication is in progress.  Then you exit, navigate away or otherwise, which cases a Terminate.  Lets say for the sake of this example the SCO calls Commit("") again, then subsequently Terminate().  It sounds like the LMS would have up to 3 active Commit("") or HTTP calls in tow at this point.  Depending on DNS lag or Server load it sounds like that could be a possible out of order scenario.  

Powered by Zendesk