Best practices for the use of Commit in SCORM content
Overview
This document suggests some best practices for the use of Commit in SCORM content.
The Commit function in the SCORM API (LMSCommit in the older SCORM 1.2) is defined by IEEE Standard 1484.11.2. It is intended to signal to the runtime environment that the data sent by the Sharable Content Object (SCO) should be committed to persistent storage. This is an optional optimization. Calling commit is not strictly necessary, since calling Terminate (LMSFinish in SCORM 1.2) will have the same effect. However, calling Commit judiciously can help make SCORM content work more reliably in some LMS implementations.
When to call Commit
Generally speaking, your SCO should call Commit if some values have been set through a SetValue call, but you anticipate that there will be a significant delay until SetValue will be called again. After setting a bookmark, for example.
When not to call Commit
Commit should not get called between SetValue calls that immediately follow each other. Rather, think of it as a "batch submit" button, a way of telling the runtime environment "This was a batch of data, now is a good time to deal with that batch."
What happens when you call Commit?
Because Commit is intended to support optional optimizations, what happens when you call Commit depends on the implementation of the runtime provided by the LMS. Some implementations might simply do nothing. Other implementations might use the call to signal that data can be moved from a transaction cache to persistent storage. Others use Commit as a signal to transmit a batch of data from the client side of the runtime environment to the server side of the runtime environment. Communication between a client and a server over the Internet can be fairly slow, especially if there additional delay caused by writing content into a database. On the other hand, communication between a SCO and the runtime environment is synchronous through the ECMAScript interface. So, some LMS implementations use a local cache that can respond instantaneously along with asynchronous communication between the client side and the server side to send the data. In other words, commit can help some LMS to manage more efficiently how and when the data is transmitted from the client side to the server side of the runtime environment, and can be particularly useful with slower or less reliable network connections.
Problem situations
At least one LMS implementator misunderstood the meaning of Commit to mean "this data will not change again in this session". That is of course problematic since the intent of the standards designers was to allow both GetValue and SetValue to happen at any time and in any order, to be finalized only at the end of the attempt. If you deal with such a LMS, you should avoid using Commit for data that will change. For example, you might use Commit after recording the data for an interaction object, as long as you know that nothing will happen that causes that data to change.
Some implementations advertised as SCORM 1.2 "compliant" missed the part of the specification that states that LMSFinish implies a Commit action. For those few implementations, you need to add LMSCommit call just before LMSFinish in a SCORM 1.2 SCO. In any case, this does not do any harm when the same SCO is run in a conformant LMS.
Conclusion
Your SCO will work if you don't call Commit, but you can help the LMS to work more efficiently and robustly if you call Commit judiciously. Definitely do not call Commit after every SetValue call.
Bibliography
1484.11.2-2003 IEEE Standard for Learning Technology - ECMAScript Application Programming Interface for Content to Runtime Services Communication (2004). Piscataway, NJ: IEEE.
This work is licensed under a Creative
Commons Attribution-ShareAlike 2.5 License.