Re: Change of Logging Status: Implications?

Will Hartung - Master Rallyeist wrote: > > [ From no logging to logging problems ] > > I, personally, am a big fan of transactions. They let programmers do > all sorts of horrible things to the data, and then when they discover > a problem, they just go "Oops! Just Kidding!" and rollback. Makes > things a LOT easier, and they also protect us from crashes in the > code. > I like the response and have two thing to add. 1) We have been using transactions for a couple of years. The main problem I found is the definition of transaction: an ATOMIC expression. For rollback, it is easy. Whenever you find something wrong, just roll it back. However, I always found programs that either issued excessive commits issued too few commits. The key to the issue is ATOMIC. 2) What transaction isolation level are you going to use? Ideally, you should consider different isolation level for every transaction. But you don't have the time. If your default isolation level is repeatable read, you will definitely have concurrrency problems. Although repeatable read is the default for ANSI standard database, it really depends on the tool you are using and your requirements. I have been insisting on repeatable read for years. I now have a second thought. Maybe committed read is the better default. Chao