5 Replies Latest reply on Jan 11, 2005 9:56 PM by bill.burke
      • 1. Re: Tx Recovery Prototype

        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
         {
         baos.reset();
         ObjectOutputStream oos = new ObjectOutputStream(baos);
         oos.writeObject(obj);
         byte[] bytes = baos.toByteArray();
         os.writeInt(bytes.length);
         os.write(bytes);
        + 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

          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.

          Bill

          • 3. Re: Tx Recovery Prototype

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

             public void commit()
             throws RollbackException,
             HeuristicMixedException,
             HeuristicRollbackException,
             java.lang.SecurityException,
             java.lang.IllegalStateException,
             SystemException
            


            • 4. Re: Tx Recovery Prototype
              bill.burke

              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

                forgot to say the above bench is with RH 8.0