[IndexedDB] coupled transactions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[IndexedDB] coupled transactions

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

Reply | Threaded
Open this post in threaded view
|

Re: [IndexedDB] coupled transactions

Kyle Huey-2
On Sun, Nov 18, 2012 at 7:54 AM, Kyaw Tun <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

RE: [IndexedDB] coupled transactions

Kyaw Tun
>
> I don't understand why the two transactions need to be coupled.


I want to use more efficient cursor walk in single transaction or
reuse transaction, since I know keys will be coming in order.

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


I got it. Thanks. Must decouple them with write transaction.

>
>
>
> - Kyle


Bufferring keys in consumer object may get efficient retrieval. Let me
know if there any efficient way to retrieving them.