Discussion on the different modes of saving changes to the database in an ARIS Report.
In ARIS Report you can influence the behavior how the report stores its changes with the following command:
ArisData.Save(-save_mode-)
where -save_mode- is one of the following:
Constants.SAVE_IMMEDIATELY
Constants.SAVE_AUTO
Constants.SAVE_ONDEMAND
Constants.SAVE_NOW (not really an own mode, just works together with SAVE_ONDEMAND)
In ARIS 7 the default „save mode“ was SAVE_IMMEDIATELY, each change of an attribute, element property or new items (e.g. in a model) was saved immediately in the database just while the command (e.g. model.createObjOcc( ) was executed .
In ARIS 9 this behavior leads to very poor report performance for all reports which change database content, because changes in the ARIS 9 database are very expensive (while read operations should be a little faster). So the default save mode in ARIS 9 was no longer SAVE_IMMEDIATELY. It was changed to SAVE_AUTO.
Advantages of, disadvantages of and hints for different save modes:
Constants.SAVE_IMMEDIATELY – the default in ARIS 7
All changes will be stored immediately into the database. Resets "SAVE_ONDEMAND" to "SAVE_IMMEDIATELY".
Advantage:
- You are sure everything is stored consistently after each operation.
- In case of an error, all errors/exceptions are thrown by the method call which causes the error.
Disadvantage:
- In ARIS 9 this leads to slow performance in scripts with some/many small write operations, because the DB update is quite slow.
Constants.SAVE_AUTO
Default setting. All changes are optimally stored in the database. In contrast to SAVE_IMMEDIATELY, objects are stored in larger blocks just early enough before the next read operation occurs. Resets "SAVE_ONDEMAND" to "SAVE_AUTO".
Advantage:
- No inconsistency of read data possible (like it could occur with SAVE_ONDEMAND), because all changes are always written automatically before the next read operation is performed on the database.
Disadvantage:
- There may exist script which do alternating read/write operations. This avoids the optimization from having an effect.
- Some write operation contain an internal “read” operation (e.g. delete an ObjDef), so the optimization may not work perfectly under all conditions.
- You cannot be sure if your change didn’t cause an error, because some errors are thrown while saving to the database. So a consistency/save exception may occur first while the script executes the next read command.
Constants.SAVE_ONDEMAND
All subsequent changes to ARIS elements will be stored to the database when Save(Constants.SAVE_NOW) is invoked for the next time.
SAVE_NOW stores all changes in mode Save(Constants.SAVE_ONDEMAND). The mode SAVE_ONDEMAND remains active.
This gives you full control when to save your changes. At the end of the script all open changes are written.
(This is not a transaction. You cannot rollback changes)
Advantage:
- Full control when to save, giving the script developer the possibility to define blocks in his script suitable for blocked saving, avoiding “micro-save operations”.
- Best possible performance (if it is used intelligently).
Disadvantage:
- Developer must be aware that all “read” operations do not consider his changes until SAVE_NOW is called. So everything that is read between to save operations must be independent from the changes done in this block.
- You cannot be sure if your change didn’t cause an error, because some errors are thrown while saving to the database. So a consistency/save exception may occur first while SAVE_NOW is invoked.
