W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Persistent Storage vs. Database

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 8 Mar 2013 11:02:24 -0800
Message-ID: <CALRQH7_WaRhZpbG+doK2s3rgTVgz1kFxY-qm=6pV2QM_vm25iw@mail.gmail.com>
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.


>  - 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:59 UTC