To Persist an object, or collection of objects, means to make them somehow survive beyond the life of the process that holds them in its memory. Conventionally, the objects are saved onto a hard disk, within a file, a storage stream, or a database. (They might also be Persisted into NVRAM, but that’s an uncommon case with regular PC used in the office). However, within the runtime, we will use the terms Persist and Persistence in the stronger sense of saving the objects to disk, and retrieving them afterwards, under the protection of transactions. In this situation, the objects are most likely stored in relational databases, whose table layout does not parallel their layout in memory.
[Outside of the runtime, the word “persist” is commonly used for the simple act of writing data to a durable medium, such as a disk, irrespective of whether that operation is transactioned or not. Wherever there might be a doubt as to what we mean in this spec, we’ll talk about “Transacted Persistence”]
Implicit to Transacted Persistence is the notion that an object retains its unique identity, and that there is only one instance of that object being acted upon at any one moment in time. For example, there can be one and only one object representing the customer called “Guadeloupe McPherson”, of the bank called “Mohavi Mutual” at any instant – it is crucially important that his SSN is 123-45-6789 and his current bank balance is $4,321. If somehow, it were possible to construct two separate instances of “Guadeloupe McPherson” we open the flood-gates of unsynchronized access to data. This contrasts with simple Serialization, where we may store a Windows form into a file, which others can copy into their address space as many times as desired.