string dbPath = @"S:\temp\STS\test1_SSD.stsdb";

        STSdb.MTL.STSdbMTLengine _sts_engine = null;

        //VERY IMPORTANT, in the Dispose function of your application main thread or DLL to say 
        //if (_sts_engine != null)
        //        _sts_engine.Dispose();

        private void testSTSdbMTL()
        {
            if (_sts_engine == null)
                _sts_engine = new STSdb.MTL.STSdbMTLengine(dbPath); //STSdb has virtual file system layer, also database can be created from many files located in different places.

            using (STSdb.MTL.Transaction tran = _sts_engine.GetTransaction())
            {
                //transaction is started, the whole code inside of using statement better to put into try/catch block

                //here we can register tables which have to be modified, and get 100% defense from the deadlocks.

                tran.RegisterWriteOrSynchroReadTables("table1/mainInfo", "table1/extras");

                //we've reserved these two tables for mutation inside of our transaction.

                //we DON'T NEED to register tables, if only one (or less) table must be mutated or eSelectMode.READ_SYNCHRO within one transaction.

                //we must register BEFORE any "write-bid" appears in the transaction, but it's possible to register after eSelectMode.READ statements 

                //Now, we want to insert rows into two different tables. Tables will be created and supported automatically, if they don't exist.

                DateTime now = DateTime.Now;
                tran.Insert<long, string>("table1/mainInfo", now.Ticks, "serialized main info");
                tran.Insert<long, string>("table1/extras", now.Ticks, "serialized extras");

                //STSdb is a Key/Value Storage (complex keys are supported), so first type "long" is our key, second type "string" is our data.
                //Documentation about STSdb better to get on their website http://stsdb.com/stsdb-user-forum/

                //Then we have to commit all operations. If we don't commit, data will not be changed
                tran.Commit(); //already in db

                //STSdb.MTL.Transaction methods like Insert, Update, Select SelectForward, SelectBackward etc. have lots of overloads, so use them.

                //No we want to select something and change it.

                STSdb.MTL.TableRow<long, string> tr = tran.Select<long, string>("table1/mainInfo", STSdb.MTL.eSelectMode.READ_SYNCHRO, now.Ticks);

                //update of the value
                tr.Value = "new value";

                //update of the key
                tr.Key = 4568; //new key

                tran.Commit(); //already in db

                //or loop

                foreach (var row in tran.SelectBackward<long, string>("table1/mainInfo", STSdb.MTL.eSelectMode.READ, 20, 8).Take(2))
                {

                    //Don't use .Where(r=>...) after LINQ Extensions Select, therefore extra range queries extensions were developed: SelectForward and SelectBackward.
                    //All computations must be made here in a loop
                    //You can use .Take() to limit quantity of data, if necessary.
                    //Or safely break; from here if quantity of checked records is enough.

                    Console.WriteLine(DateTime.Now.Ticks.ToString() + " " + DateTime.Now.ToString("mm:ss.ms") + " > Key: " + row.Key.ToString() + " ;;; Value: " + row.Value.ToString());
                }

                //BTW. if table is mutated and still not committed, selects of this table with eSelectMode.READ_SYNCHRO, 
                //within the same transaction, shows changed values,
                //though selects of this table with eSelectMode.READ will go on to show unmodified data (sure, till Commit).


                //With eSelectMode.READ_SYNCHRO you can be sure that you take the latest modified value, 
                //then you can modify it in your thread and Commit it, 
                //the next concurrent thread will take exactly your modified value. 
                //If there are concurrent threads which want to update the same table as your transaction thread and at the same time, 
                //they will have to wait, till your transaction is finished (not committed, because you can commit 
                //several times in one transaction, but finished).

                //Otherwise, the threads, who want to eSelectMode.READ values, will receive them fast and in parallel 
                //with the thread who is making modification and with each other.

                //Only select and show - use eSelectMode.READ 
                //Select and then update value in the same transaction - must be used eSelect.READ_SYNCHRO 

                //eSelectMode.READ - reporting style. 
                //eSelectMode.READ_SYNCHRO - bank account value change style. 
            }
        }



Last edited Dec 14, 2011 at 12:41 PM by hhblaze, version 1

Comments

No comments yet.