-
1. Re: Tx Recovery Prototype
adrian.brock Jan 10, 2005 5:24 PM (in response to bill.burke)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 Jan 10, 2005 6:10 PM (in response to 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
adrian.brock Jan 10, 2005 7:09 PM (in response to bill.burke)The example I saw was the throws aren't embedded making it difficult to
pick out the method namepublic void commit() throws RollbackException, HeuristicMixedException, HeuristicRollbackException, java.lang.SecurityException, java.lang.IllegalStateException, SystemException
-
4. Re: Tx Recovery Prototype
bill.burke Jan 11, 2005 9:55 PM (in response to 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 Jan 11, 2005 9:56 PM (in response to bill.burke)forgot to say the above bench is with RH 8.0