New API for enabling bulk IO

[grecinto]

There are two new APIs in B-Tree interface: Lock & Flush. Both of these are designed to allow developer to do equivalent of bulk IO in traditional databases.

• Lock - locks the table for either writing or reading. Will rollback & error if lock can't be attained. Upon lock attainment, other B-Tree managers in the cluster can only share lock if "for read" and can't if "for write" was requested. Also, if there is a "for write" ongoing, any "for read" lock request will fail right away.
• Flush - allows developer to persist changes in B-Tree (table) to the backend storage. Does not change the transaction usage pattern, 'still, commit or rollback govern the transaction.

Sample usage to illustrate pattern of use:

b3.Lock(ctx, true)
for i := 0; i < 2000; i++ {
pk.Firstname = fmt.Sprintf("hello%d", i)
b3.Add(ctx, pk, p)
}

// flush all 2,000 inserts to the backend storage to given chance to unburden the engine, reduce memory for rarely used Nodes, etc...
b3.Flush(ctx)

for i := 2001; i < 4000; i++ {
pk.Firstname = fmt.Sprintf("hello%d", i)
b3.Add(ctx, pk, p)
}

// Finalize all the changes & release any lock on any B-tree(s) participated in the transaction.
trans.Commit(ctx)

// Or Rollback, will also release the B-tree(s) lock(s).

[grecinto]

Auto flush will remove need to call "Flush" function. Not too sure if flush is really needed though, since it can be auto-flushed. Flush method may not be necessary, but an auto save (or auto-persist & pruning of MRU) can internally be occurring every certain load is reached.

The MRU cache itself can drive this "auto-flush" feature.

[grecinto]

The current BtreeInterface is sufficient to do bulk IO, by usage. Like ensure there is not much conflicts on data being processed across transactions.

However, in the future, when time permits, we may add support for "Lock" B-tree method. Closing this for now, as we can always file a new item for it or re-open this ticket.