- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Fri, 8 Mar 2013 11:02:24 -0800
- To: Kyle Huey <me@kylehuey.com>
- Cc: public-webapps <public-webapps@w3.org>
On Thu, Mar 7, 2013 at 10:36 PM, Kyle Huey <me@kylehuey.com> wrote: > On Thu, Mar 7, 2013 at 10:20 PM, Andrew Fedoniouk > <news@terrainformatica.com> wrote: >> >> Physical commit (write) of objects to storage happens on either >> a) GC cycle or b) on explicit storage.commit() call or on c) VM shutdown. > > > Persisting data off a GC cycle (via finalizers or something else) is a > pretty well known antipattern.[0] Raymond is right in general when he speaks about .NET runtime environment. But JS computing environment is quite different from the .NET one - at least these two have different lifespans of VMs and memory heaps. In my case persistence is closer to virtual memory mechanism - when there is not enough memory persistable objects get swapped to the storage from the heap. That is quite widespread pattern if we want to use this language. In any case there is always storage.commit() if you need guarantees and deterministic storage state. > >> At least it is easier than http://www.w3.org/TR/IndexedDB/ :) > > > Easier doesn't necessarily mean better. LocalStorage is certainly easier to > use than any async storage system ;-) > At least my implementation does not use any events. Proposed system of events in IndexedDB is the antipattern indeed. Exactly for the same reasons as finalizer *events* you've mentioned above - there is no guarantee that all events will be delivered to the code awaiting and relaying on them. -- Andrew Fedoniouk. http://terrainformatica.com > - Kyle > > [0] e.g. > http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx
Received on Friday, 8 March 2013 19:02:56 UTC