Persist sessionStorage on disk.

webkit/dom_storage/dom_storage_context.cc

Index: webkit/dom_storage/dom_storage_context.cc
diff --git a/webkit/dom_storage/dom_storage_context.cc b/webkit/dom_storage/dom_storage_context.cc
index e31019067cea7b9922f5e894dd30e741c1d0b5c9..175316d4758ed5cdf3514a72274103376bbea44c 100644
--- a/webkit/dom_storage/dom_storage_context.cc
+++ b/webkit/dom_storage/dom_storage_context.cc
@@ -10,9 +10,11 @@
 #include "base/location.h"
 #include "base/time.h"
 #include "webkit/dom_storage/dom_storage_area.h"
+#include "webkit/dom_storage/dom_storage_database.h"
 #include "webkit/dom_storage/dom_storage_namespace.h"
 #include "webkit/dom_storage/dom_storage_task_runner.h"
 #include "webkit/dom_storage/dom_storage_types.h"
+#include "webkit/dom_storage/session_storage_database.h"
 #include "webkit/quota/special_storage_policy.h"
 
 using file_util::FileEnumerator;
@@ -38,6 +40,10 @@ DomStorageContext::DomStorageContext(
   // namespace ids at one since zero is reserved for the
   // kLocalStorageNamespaceId.
   session_id_sequence_.GetNext();
+  if (!sessionstorage_directory_.empty()) {
+    session_storage_database_ =
+        new SessionStorageDatabase(sessionstorage_directory_);
+  }
 }
 
 DomStorageContext::~DomStorageContext() {
@@ -87,6 +93,7 @@ void DomStorageContext::GetUsageInfo(std::vector<UsageInfo>* infos,
       infos->push_back(info);
     }
   }
+  // FIXME(marja): Get usage infos for sessionStorage (crbug.com/123599).
 }
 
 void DomStorageContext::DeleteOrigin(const GURL& origin) {
@@ -146,6 +153,16 @@ void DomStorageContext::Shutdown() {
         base::Bind(&DomStorageContext::ClearLocalStateInCommitSequence, this));
     DCHECK(success);
   }
+
+  // If the last exit was unclean, the session storage backing might contain
+  // leftover data. Delete it now.
+  // TODO(marja): When doing a session restore, protect parts of the data from
+  // deletion.
+  bool success = task_runner_->PostShutdownBlockingTask(
+      FROM_HERE,
+      DomStorageTaskRunner::COMMIT_SEQUENCE,
+      base::Bind(&DomStorageContext::DeleteLeftoverDataInCommitSequence, this));

[michaeln, 2012/04/22 21:43:35]

it might be premature to have this here, feels like how/when to identify which
areas to retain and which to nix is not entirely worked out

[marja, 2012/05/11 12:18:32]

Should I make it so that this CL just deletes all data on clean exit (as it's
not going to associate the data back to the Namespaces after restoring the
session)?

How I think this could work:
- Normally, DeleteSessionNamespace is called for each namespace on exit.
- At that time, we know if we're going to restore the session or not.
- If we're not going to restore, then just delete the data as it is now.
- Also, we need some way to delete the data after a crash: there will be data in
the database but no DomStorageSession or SessionStorageNamespaceImpl classes
associated with it. When should we delete such data? On a clean exit?
- If we're going to restore, the session restore system would tell
DomStorageContext a list of namespace IDs that should be protected from
deletion. DeleteSessionNamespace wouldn't tell delete those. (This functionality
would be in a separate CL.)

So, in this CL I would do this:
- DeleteSessionNamespace always deletes the data.
- We also (somehow) delete the data which is left over after a crash.

In the next CL, I would do this:
- On exit, when we're going to restore, protect parts of the data from deletion.
I'd imagine this works so that the session restore system keeps track of what
namespace id's are associated with the tabs it knows about, and on exit, gives
that list to DomStorageContext.
- When restoring a session, associate the data in the database with the restored
tabs.
- We don't always restore the session after a crash, so that leftover data still
needs to be deleted somewhere.

Wdyt?

[michaeln, 2012/05/16 08:10:55]

Maybe don't try to answer this question just yet, and instead make progress on
parts we are certain about (DomStorageArea + session db backing). As coded this
method will delete everything provided there's a clean shutdown (so what why
bother having written it to disk). Let's have chromium built from trunk not
write to disk until its ready to restore from disk.
about when to delete dead stuff, incrementally while up and running is probably
the best answer, at startup isn't an option at all, at shutdown doesn't happen
sometimes and when it does happen a million other things happen too (so it takes
quite a while already)
another way to think about it maybe... DomStorageContext assumes by default that
all new and existing session are to be kept forever... until session restore
says otherwise, DomStorageContext then remembers which its been told can go away
will eventually make those go away.

So as session restore figures out something is no longer needed, it call
DSC.RevokeSessionStorage(id) or some such method. And when doing 'restore', the
session restore can query DSC for a list of unrevoked session ids and call
revoke on those not needing to be restored.

It's probably worth taking a stab at that session restore logic prior to coming
to any final decisions about this aspect of things.

+  DCHECK(success);
 }
 
 void DomStorageContext::AddEventObserver(EventObserver* observer) {
@@ -191,14 +208,31 @@ void DomStorageContext::CreateSessionNamespace(
     return;
   DCHECK(namespace_id != kLocalStorageNamespaceId);
   DCHECK(namespaces_.find(namespace_id) == namespaces_.end());
-  namespaces_[namespace_id] = new DomStorageNamespace(
-      namespace_id, task_runner_);
+  if (session_storage_database_.get()) {
+    // Session storage with backing.
+    namespaces_[namespace_id] = new DomStorageNamespace(
+        namespace_id, session_storage_database_.get(), task_runner_);
+  } else {
+    // Session storage without backing.
+    namespaces_[namespace_id] = new DomStorageNamespace(
+        namespace_id, task_runner_);
+  }
 }
 
 void DomStorageContext::DeleteSessionNamespace(
     int64 namespace_id) {
   DCHECK_NE(kLocalStorageNamespaceId, namespace_id);
   namespaces_.erase(namespace_id);
+  // TODO(marja): When doing a session restore, protect parts of the data from
+  // deletion.

[michaeln, 2012/04/22 21:43:35]

maybe the way the session handling logic in chrome keeps sessions alive across
restarts is by setting a 'restorable' attribute on those
SessionStorageNamespaces, and this lower level logic would avoid deletion of
them.

[marja, 2012/05/11 12:18:32]

Hmm, not sure yet how this would work.

Could the session restore system tell DomStorageContext a list of namespace ids
not to delete, and they would then be protected from deletion in this function?
(The "which namespace ids are in the session restore data" would be somewhat
easy to maintain. I'm atm slightly confused about which tabs would be restorable
(by the session restore, only the open ones, but by the tab restorer, some
others, and how could SessionStorageNamespaceImpl get to know that...)

+  if (session_storage_database_.get()) {
+    bool success = task_runner_->PostShutdownBlockingTask(
+        FROM_HERE,
+        DomStorageTaskRunner::COMMIT_SEQUENCE,
+        base::Bind(&DomStorageContext::DeleteSessionNamespaceInCommitSequence,
+                   this, namespace_id));
+    DCHECK(success);
+  }
 }
 
 void DomStorageContext::CloneSessionNamespace(
@@ -237,4 +271,13 @@ void DomStorageContext::ClearLocalStateInCommitSequence() {
   }
 }
 
+void DomStorageContext::DeleteSessionNamespaceInCommitSequence(
+    int64 namespace_id) {
+  session_storage_database_->DeleteNamespace(namespace_id);
+}
+
+void DomStorageContext::DeleteLeftoverDataInCommitSequence() {
+  session_storage_database_->DeleteLeftoverData();
+}
+
 }  // namespace dom_storage