- summary: datamodels not --> datamodels should be cloned after every major state change
Whenever an algorithm is run in the IVCSF, it is handed a reference to
the datamodel currently selected. However, nothing makes sure that
this datamodel has actually been saved before being handed over to
the next algorithm.
Problems with this approach:
- Two algorithms can be concurrently modifying the same datamodel!
- Intermediate state information of the datamodel is completely lost.
Possible Solutions:
Each time a datamodel is added to the ivcsf, we need to transparently
make a copy of the object and hand it to the next algorithm. However,
since there's no reliable way of performing cloning in memory of
objects, we will most likely have to persist the data and make a copy
from the persisted data in the background. I see two ways of doing this
at the moment:
1. Use persisters
- When a datamodel is loaded into memory from a resource, we can
keep track of the persister that loaded the data and use it to store the
state of a datamodel to file.
- When a datamodel is created in memory by an algorithm, find some
persister that can persist it and do the same as above. Then keep track
of which persister was chosen.
Problems:
- We haven't really solved the data loss problem. We are supposed to
be doing this copying transparently so the user cannot be interrupted
with questions like 'what persister would you like us to use to make a
copy of this data object?'. So we have no way of knowing if any given
persister will actually persist all state information. From experience,
most persisters *will* drop some state information. So we can't use this
route.
- Performance is heavily dependent on the performance of the
persister.
2. Use JOS (Java Object Serialization).
- Basically we can serialize the object into a byte stream and read the
object back in from it into a copy.
Problems:
- Objects being serialized must implement serializable, else we'll get
NotSerializableException.
- Performance is still an issue, although we can definitely optimize that
by removing stuff we don't need (defensive copying, synchronization,
etc) if we design access to this capability carefully.