Persistent objects

[deelan]

Paul Rubin wrote:
> I've had this recurring half-baked desire for long enough that I
> thought I'd post about it, even though I don't have any concrete
> proposals and the whole idea is fraught with hazards.
> 
> Basically I wish there was a way to have persistent in-memory objects
> in a Python app, maybe a multi-process one.  So you could have a
> persistent dictionary d, and if you say 
>    d[x] = Frob(foo=9, bar=23)
> that creates a Frob instance and stores it in d[x].  Then if you
> exit the app and restart it later, there'd be a way to bring d back
> into the process and have that Frob instance be there.

this sounds like the "orthogonal persistence" of
unununium python project:

Orthogonal Persistence

''A system in which things persist only until they are no longer needed 
is said to be orthogonally persistant. In the context of an OS, this 
means that should the computer be turned off, its state will persist 
until it is on again. Some popular operating systems implement non-fault 
tolerant persistence by allowing the user to explicitly save the state 
of the machine to disk. However, Unununium will implement fault tolerant 
persistence in which state will be saved even in the case of abnormal 
shutdown such as by power loss.''

from:
<http://unununium.org/introduction>

check also this thread:
<http://unununium.org/pipermail/uuu-devel/2004-September/000218.html>

''Such a solution isn't orthogonal persistence. The "orthogonal" means 
how the data is manipulated is independent of how it is stored. Contrast
this with the usual way of doing things that requires huge amounts of
code, time, and developer sanity to shuffle data in and out of
databases.''

''In fact, we do plan to write to RAM every 5 minutes or so. But, it's 
not slow. In fact, it's faster in many cases. Only dirty pages need to 
be written to the drive, which is typically a very small fraction of all
RAM. Because there is no filesystem thus the drive spends little time
seeking. Furthermore, serializing all data to some database is not
required, which saves CPU cycles and code, resulting in reduced memory
usage and higher quality in software design.''

''The resulting system is fully fault tolerant (a power outage will 
never hose your work), requires no network, and doesn't introduce any 
new points of failure of complexity.''


you may want to investigate how the UUU guys think to
implememt this in their project.


bye.

-- 
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<#me> a foaf:Person ; foaf:nick "deelan" ;
foaf:weblog <http://www.netspyke.com/> .