Re: [IndexedDB] coupled transactions

On Sun, Nov 18, 2012 at 7:54 AM, Kyaw Tun <kyawtun@yathit.com> wrote:

> Coupled transactions exists when two or more transactions should be
> committed together but transactions are in different scopes or mode.
> Currently I find this problem challenging to solve with IndexedDB API.
>
> This can be solved by merging transactions into single transaction,
> but it will be sub-optimal and require sharing transaction objects.
>
> The use case appear when we want to use producer-consumer pattern as
> follow:
>
> In producer object, a read transaction is created and index cursors
> are scanning to find a matching keys. Whenever it find a match key, it
> send to consumer object.
>
> Consumer object, a read or write transaction is created when it first
> received a key. The cursor value is use to render UI or update it to
> the database. In general, we are expecting to receive ordered sequence
> of keys. For optimal purpose, the transaction should be keep active.
>
> Concrete example:
>
> Consumer side
> ----------------------
>
> var out = new ydn.db.Streamer(db, 'animals', 'id');
>   out.setSink(function(key, value) {
>     console.log(['receiving', key, value]); // should be ['cow', 'cow']
>   });
>
>
> Producer side
> --------------------
> var q1 = ydn.db.Iterator.where('animals', 'color', '=', 'spots');
> var q2 = ydn.db.Iterator.where('animals', 'horn', '=', 1);
> var q3 = ydn.db.Iterator.where('animals', 'legs', '=', 4);
> var solver = new ydn.db.algo.NestedLoop(out);
> var req = db.scan([q1, q2, q3], solver);
>
>
> data
> ------
> animals = [
>     {id: 'rat', color: 'brown', horn: 0, legs: 4},
>     {id: 'cow', color: 'spots', horn: 1, legs: 4},
>     {id: 'galon', color: 'gold', horn: 1, legs: 2},
>     {id: 'snake', color: 'spots', horn: 0, legs: 0},
>     {id: 'chicken', color: 'red', horn: 0, legs: 2}
>   ];
>
>
>
>
>
>
> Ref: test_31_scan_mutli_query_match in
>
> https://bitbucket.org/ytkyaw/ydn-db/raw/0e1e33582cfed54c9baf1d5bb134cae58bac45c8/test/iteration_test.js
>
>
I don't understand why the two transactions need to be coupled.  The
producer object has a read only transaction, so it won't commit any
changes.  The consumer object has a read write transaction.  If it's
modifying the same object stores the producer object is reading from, that
transaction will block until the producer's transaction is inactive, so the
producer will receive a coherent snapshot of data.

- Kyle