David Faure wrote: > And given that the Aggregates table will obviously always be used this way > (updating a total), being able to set lockRows=true once and for all in the > definition of that table makes sense to me; more than having to remember to > pass "lock the rows" in each and every operation on that table - which would > be > impossible anyway for "agg.total = agg.total + newVal".
It does not seem obvious that the Aggregates table will always be used the way you describe. I would assume that the reason to store this information in the database is so that it can be retrieved from the database at some point. If the processes that retrieve this information cause row level locks to be taken out, then you are creating the following issues: - Scalability issues. Multiple readers cannot read the value from the Aggregates table at the same time, as they need to wait their turn to acquire the lock - Security issues. Connections that just need to read the value from the Aggregates table would need UPDATE permissions on the table (at least with PostgreSQL) - Deadlock issues. The more locks you take out, the more likely you are to trigger deadlocks. I think FOR UPDATE would be a good addition. I would expect it to be a parameter passed through to select. Even if people decide to go with a flag in the table definition, I think the parameter to select is still required to override the flag for the common case of only needing FOR UPDATE in rare situations. (It seems you are trying to emulate a SERIALIZABLE transaction isolation level btw. - if MySQL supports this it might be a better solution to your problem). -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
