5 Replies Latest reply on Jan 11, 2005 9:56 PM by Bill Burke

    Tx Recovery Prototype

    Bill Burke Master
        • 1. Re: Tx Recovery Prototype
          Adrian Brock Master

          Hi Bill,

          Some first comments:

          1) Force to disk
          The current implementation does not force changes to disk, i.e. you do not know
          the commit decision has been written to hardware (only the OS buffer cache).

           private void writeObject(Object obj) throws IOException
           ObjectOutputStream oos = new ObjectOutputStream(baos);
           byte[] bytes = baos.toByteArray();
          + os.getFD().sync();

          2) Why do you need a ObjectStream?
          It introduces an unecessary overhead when you know the format is in String and ints.

          3) Log is open for r/w
          This does not perform very well. It also introduces complications relating to the
          buffering implementation of the OS/device.
          In general logs should be only open for write, giving superior performance
          and also avoiding potentially nasty buffers corruptions across threads
          of what you think is already synced data.

          4) The RecoveryLogTerminator needs to be stored in the TransactionImpl
          across prepare/commit for the external transaction commit.

          5) You need to fix your "pretty print" it has done some horrible things with the
          source formatting. It would also be a good idea to run "pretty print" before
          making changes so we can actually see the changes on the cvs commit.

          • 2. Re: Tx Recovery Prototype
            Bill Burke Master

            On 1) it is opened as "rwd". Just read someplace that "rwd" is not guaranteed on all OSs (although it says it is).

            2) THis was just a quick and dirty impl. ObjectStream was used to make sure data is valid. In future some kind of hash or checksum can be used.

            3) You don't have to worry about corruption if only one thread is writing to disk. I chose RAFs because of the setLength option.

            4) I didn't put much thought into externalized txns yet. I think I'll have to have some sort of base id within the branch as well. When pruning what resource xids can be recovered, I'll need to take into account the base branch id as well. Currently I'm pruning only based on globalid. Anyways, external txns won't work anyways, because I didn't put in recovery in the prepare() method that's called by the terminator.

            5) Define horrible. I thought I set my IDE to use the jBoss coding standards maybe I missed something.


            • 3. Re: Tx Recovery Prototype
              Adrian Brock Master

              The example I saw was the throws aren't embedded making it difficult to
              pick out the method name

               public void commit()
               throws RollbackException,

              • 4. Re: Tx Recovery Prototype
                Bill Burke Master

                Ok, just did another version tonight. The new impl is a batch queue using nio ByteBuffers. I did some quick benching and its pretty quick. Got a max of about 17,000 txs/second with 1030 threads running in parallel. THis is with a dual-cpu xeon 2.4 Ghz with 10,000 rpm scsi.

                Also updated the WIKI page on recovery with new thoughts.

                • 5. Re: Tx Recovery Prototype
                  Bill Burke Master

                  forgot to say the above bench is with RH 8.0