Re: ACID et al

You might want to look into the architecture of SAP R/3, which seems to be pretty close to what you're thinking about:

• database transactions aren't kept open over screen input. That way, the expensive database session can be used for user B while user A is still entering input.
• most db transactions run in isolation level 0 to minimize conflicts, changing commands are sent to a special queue (though I don't know whether this is one per database or one per application server, there may be several application servers that access the same database)
• an 'R/3 transaction' spans therefor several db transactions (if SELECTs in isolation level 0 can be called a db transaction at all)
• I don't know how clients coordinate themselves. I suppose they set some flag to indicate someone is working on customer X, therefor locking (not db locking) all related records.

There is a rather large infrastructure built around the programming environment (data dictionary etc.). Additional programs should never access the database directly. This means that the 'system' is really R/3 and not the database.

But the database engines still need row level locking (database engines using page level locking were not scalable enough). While db locks might be less relevant in certain parts of the system, they seem to be still very important in others.

Daniel Received on Tue Dec 06 2005 - 11:35:08 CET