Persistence Definition

Definition?

I think a problem here is that "persistence" is not clearly defined. I don't think it is a RAM-versus-Disk thing because those distinctions can be blurred or hidden. As a working definition, I will define "persistence" as a "shared view". One is "saving" when they move information from local, temporary uses to the "global model". In other words, we often grab info and reshape it to best fit some particular task or action and when we are done we put any sharable changes in the sharable place where other tasks/methods can use it as they see fit.

OOP does not really have a well-defined way to have global representations just sit there. For example, employee objects in an HR system don't just sit out there ready to share info with other objects (and systems?). You have to instantiate a local view first (and unless polymorphism is useful, I don't see a need for such).

-- top

Your "shared view" has nothing to do with persistence. Persistence is literally this; long lifetime. Nothing more and nothing less. Transparent persistence means that objects with long lifetimes are treated exactly the same as objects with short ones.

What you call "shared view" has to do with sharing and security of objects. And sharing, or publishing as it's often called, has absolutely nothing to do with saving. And OOP does provide a model for secure publishing, called CapabilitySecurityModel, which databases and such do not define. Instantiation has nothing to do with any of this. -- rk

Maybe longevity and sharing are related directly or indirectly. In most examples I can think of they are. One generally does not keep stuff laying around for a very specific task. It is comparable to cleaning up your desk after you done with a project. You put the savable stuff into folders and file them away in case you need it for other purposes in the future. But perhaps I am blinded by physical desk thinking and there are other ways to organize tasks.

My thinking has been to grab the shared view of the data, format it or reprocess it for a local, specific task, and then dump it when finished. Any given "fact" tends to be used by multiple processes or tasks, at least here in Cubicle Land. Thus, it makes sense to have a sharable repository of some kind. However, this sharable repository cannot really be shaped for a specific task since it is used by multiple tasks. This is something that bothers me about EncapSulation? that I have not been able to resolve in a nice way.

Persistence itself does not imply sharing. Persistence only implies survival and continuity. Persistence is a prerequisite for certain forms of communication and sharing (communication on the sneaker-net, communication between two processes that are active at different times, etc.). So the relationship you see between persistence and sharing is understandable. You simply have the relationship inverted in that mental model of yours.

Survival and continuity can be on a wide continuum. Here's a working definition to test: "Information that we wish to 'keep' and explicitly state so until the point we explicitly remove it or mark it for removal." This has a form of "intent" in the definition, which I don't like, but it makes for general starting point. This differs from transient data in that we let a process decide how long it needs to keep it. In other words, if the keeping is decided by domain issues and not "computing-space concerns", then it's persistent. -t

[Here's a simpler working definition: "Persistent" data is that which comes back after a power failure. (Tongue slightly in cheek, but only slightly.)]

What if bubble memory or something like it takes off?

[Non-volatile memory may be used to provide persistence, essentially by definition.]

It might be a facilitator to "persistence", but not automatically make everything on it "persistent". Or does it? In other words, is "persistence" about technology, or our usage of it? I vaguely remember proposed "levels" of persistence defined somewhere around this wiki.

Persistence is, by nature, a relative term. You can reasonably say that one subsystem is persistent relative to another. FileSystems are generally persistent relative to processes. The Internet is persistent relative to individual nodes or FileSystems. If the context is unclear, it would not be unreasonable to assume a discussion of 'persistence' as being 'relative to the power-cycle of the machine'.

PageAnchor: explicit_2

The "explicit save" definition is not (as) relative. Let me rework it here a bit: 'Information is "persistent" if we explicitly indicate we want to "save" it until the point where we explicitly request it be deleted.' We explicitly "flip a switch" to a save request, and flip another for a delete request. We don't have to request that memory variable values be deleted because they are done so automatically by the interpreter or garbage-collection engine. Thus, they are not "persistent". This definition is not tied to hardware, but rather to the existence of save & delete commands/methods attached to or available to a given object. (Note that I am discarding the prior "shared" featured for now.) -t

Anyhow, it doesn't take a complete definition of 'persistence' to define or grok a more specific concept such as 'TransparentPersistence'. You only need to know that, to whatever extent 'persistence' might require explicit code to serialize objects, restore objects from serialized form, and get communications and processes running again (without breaking things), and even decide when and where to perform these tasks, full TransparentPersistence does not require application programmers to write that code.

Existing architecture currently is generally based on processes and files. If information outlives a given process, it's generally considered "persistent", usually via the filing system. A given process may cache info on disk temporarily, but it's generally assumed that something may wipe that clean after the process is complete.