7 Replies Latest reply on Jul 10, 2012 10:54 AM by user12103686

    AWT cache group with CacheAwtParallelism

    user12103686
      I have some question.

      TTversion : TimesTen Release 11.2.2.3.0 (64 bit Linux/x86_64) (tt112230:53376) 2012-05-24T09:20:08Z

      We are testing a AWT cache group ( with CacheAwtParallelism=4 ).

      Application(1 process) to the DML generates to TimesTen(DSN=TEST).

      At this point, Are delivered to the 4 parallel DML?

      ######################
      [TEST]
      Driver=/home/TimesTen/tt112230/lib/libtten.so
      DataStore=/home/TimesTen/DataStore/TEST/test
      PermSize=1024
      TempSize=512
      PLSQL=1
      DatabaseCharacterSet=KO16MSWIN949
      ConnectionCharacterSet=KO16MSWIN949
      OracleNetServiceName=ORACLE
      OraclePWD=tiger
      CachegridEnable=0
      LogBufMB=512
      LogFileSize=1024
      RecoveryThreads=8
      LogBufParallelism=8
      CacheAwtParallelism=4
      ReplicationParallelism=4
      ReplicationApplyOrdering=0
      UID=scott
      PWD=tiger
      ######################

      Thank you very much.

      GooGyum
        • 1. Re: AWT cache group with CacheAwtParallelism
          Gennady Sigalaev
          Hi GooGyum,

          CacheAwtParallelism parameter shows the number of threads that should be used to apply changes to the Oracle database (http://docs.oracle.com/cd/E21901_01/doc/timesten.1122/e21643/attribute.htm#BABHEGBB).
          It means that your application executes DML into TimesTen, but after that TimesTen transfers these changes to Oracle DB by using 4 threads (it was only one thread in earlier versions).

          Best regards,
          Gennady
          • 2. Re: AWT cache group with CacheAwtParallelism
            ChrisJenkins-Oracle
            Let me try and elaborate a littleon 'parallel AWT' (and parallel replication). AWt uses the Timesten replicatio ninfrastructure to capture changes made to AWT cached tables and propagate those changes to Oracle DB. The replication infrsatructure captures changes to tables by mining the TimesTen transaction (redo) logs. The replication/AWT capture/propagate/apply processing is completely decoupled from application transaction execution.

            In TimesTen releases earlier than 11.2.2, the replication infrastructure was completely single threaded in terms of capture/propagate/apply. This means that if you have a TimesTen datastore with several application processes, each with multiple threads, all executing DML against TImesten there is just a single replication thread capturing all these changes, propagating them to the target and applying them there. This was clearly a performance bottleneck in some situations. In 11.2.2 the replciation infrastructiure has been parallelised to improve performance. This is a very dififcult task as we still need to guarantee 'correctness' in all scenarios. The implementation tracks both operation and commit order dependencies at the source (i.e. where the transactions are executed) and encodes this dependency information into the replication stream. Changes are captued, propagated and applied in parallel and on the apply side the edependency information is used to ensure that non dependant transactions can be applied in parallel (still subject to commit order enformcement) while dependant transactions are always applied in a serial fashion. So, depending on the actual workload you may see significant performance improvements using parallel replication / parallel AWT.

            Note that parallelism is applied between transactions; there is no parallelism for the operations within an individual transaction.

            In the case mentioned, CacheAwtParallelism=4, this means that up to 4 threads will be used to apply transactions in parallel to Oracle. The actual degree of parallelism obtained is subject to inter-transactional dependencies in the workload and adjusts dynamically in real-time.

            Chris
            • 3. Re: AWT cache group with CacheAwtParallelism
              user12103686
              thanks for answer. :)

              <1 Process Application>Txn, Txn-1, ... Tx4,Tx3,Tx2,Tx1(ordering) => TimesTen -> cache thread 1(Tx1,...) => Oracle
              ---------------------------------------------------------------------------------------------------->cache thread 2(Tx2,...)
              ---------------------------------------------------------------------------------------------------->cache thread 3(Tx3,...)
              ---------------------------------------------------------------------------------------------------->cache thread 4(Tx4,...)
              Did this mean?

              Thankyou very much.

              GooGyum

              Edited by: user12103686 on 2012. 7. 10 오전 2:18
              • 4. Re: AWT cache group with CacheAwtParallelism
                Gennady Sigalaev
                I think, yes.

                regards,
                Gennady
                • 5. Re: AWT cache group with CacheAwtParallelism
                  user12103686
                  thanks for answer. :)

                  <1 Process Application>Txn, Txn-1, ... Tx4,Tx3,Tx2,Tx1(ordering) => TimesTen -> cache thread 1(Tx1,...) => Oracle
                  ---------------------------------------------------------------------------------------------------->cache thread 2(Tx2,...)
                  ---------------------------------------------------------------------------------------------------->cache thread 3(Tx3,...)
                  ---------------------------------------------------------------------------------------------------->cache thread 4(Tx4,...)
                  Did this mean?

                  I think it's important commit order.
                  Have the option to TimesTen about commit order?

                  Thankyou very much.

                  GooGyum
                  • 6. Re: AWT cache group with CacheAwtParallelism
                    ChrisJenkins-Oracle
                    I did already explain this (I thought). Commit order is paramount. TimesTen parallel replication / parallel AWT always maintains commit order; propagated transactions are always comitted in the same order as they were executed in Timesten. There is no option to disable this behaviour. The operations within different transactions may be applied in parallel to each other as long as there are no data dependencies between the transactions/operations; if ther are dependencies then the transactions are applied sequentially. There is no option to disable this either. If we were to allow the disabling of inter-transactional dependency and commit order checking and enforcement it would likely allow higher performance but would also allow incorrect behaviour resutling in data inconsistency. Correctness is paramount.

                    Chris
                    • 7. Re: AWT cache group with CacheAwtParallelism
                      user12103686
                      thanks for answer.

                      Thankyou very much.

                      GooGyum