Re: Transactions: good or bad?

> >
> > Anyway I think you are confusing transactions with data models. Don't.

They are one and the same. A theoretical data model is useless if it cannot be implemented. While it is useful to start a design with a theoretical model considered without implementation, if, it turns out that the theoretical model nicely shoved some theoretically impossible to implement glitch under the covers of implementation, then the theoretical model must give way to practical engineering.

My previous point was that because of the set oriented nature of databases, they more or less demand transactions to implement. I corrected myself because I realized that I could get good concurrency by having instruction level atomicity, thus, avoiding the need for transactions, and multiple users can still use the system concurrently because different instructions can still run in parallel. It's basically a processor model. Now, data level concurrency can still be achieved to further the cause of concurrency. In my case, profile instructions (such as add two profiles, etc), can run concurrently.

This still does not solve the problem of phantom rows. But, a user level locking mechanism can work for me in my case because the clients are not always connected.

> > So don't loose your time beating a dead horse.

It's impossible to find any information on the topic, because Google has decreed that Database Assignment means: "help me with my homework". If you have a URL, I will gladly read it. Received on Mon Jun 09 2003 - 17:43:03 CEST