IndexedDB access from multiple iFrames having same domain

Question

I have a few iFrames on the page with the similar domain as the parent(So, no CORS issue here, why do I have iFrames then? That's a long story and involves Shindig Gadget Server etc etc.)

Problem Statement: Each iFrame has loads of data that it needs to store locally(cannot use local/sessionStorage because of the huge amount of data) in the IndexedDB as soon as the iFrame renders and later interact with that data too.

Soultion I thought of: Each iFrame can have a different objectStore inside a single DB instance in IndexedDB which the frame can interact with(insert/update/delete) without polluting any other frame's data. Along with the iFrames the parent page has also got some data to save which will also be stored within the IndexedDB in some other objectStore specific to the parent.

Type of data to Store: It's a simple key-value pair where first column key is a string(the unique key) and the value can be a simple javascript object, array or JSON.

Issues: First off, I want to know if such a design is possible. I am doubtful because I wrote a simple program with 2 iFrames. I am opening 3 connections to the same DB(frame_db, see diagram below), one in each of the iFrames and one in the parent page and trying to create 3 different objectStores (via onupgradeneeded) but only one(with the parent page) is getting created instead of three.

I want to know what am I doing wrong here, or is there a better approach to achieve this? Or is it even possible to do it? I know I can't make use of synchronous APIs such as localStorage/sessionStorage/cookies due to space constraints.

To help understand, here's a picture of what I want to achieve:

Answer 1

Database schema changes (such as creating new object stores) can only occur when a "versionchange" transaction runs, which only happens when opening with a new version, which is only able to proceed when no other connections to the database are open.

So as long as one frame has a connection to "frame_db" open, other frames won't be able to create new stores.

Two options:

• Use one database per frame instead
• Use one store for all frames, and use compound keys. E.g. instead of keys with ids 1, 2, 3... use keys of the form ["frame1", 1], ["frame1, 2] ... ["frame2", 1], ["frame2", 2], ...

The latter will allow transactions to span the data for multiple frames (which may be why you wanted a single database in the first place). It also better matches the "spirit" of IDB versioning where a schema/version change corresponds to a change to your app's use of the database.