Branko Čibej <br...@e-reka.si> writes: > The temporary table is: > > * in a different database, so the read lock on it does not affect > the main wc-db; > * per-connection, so even the same process using a different > database connection will not even see that temporary table.
OK, so the process is: - read lock on main database - write lock on temporary database - populate temporary table - release write lock - release read lock - read lock on temporary database - make callbacks - release read lock without the temporary table it could be: - read lock on main database - make callbacks - release lock What we gain is that the callback can modify the main database, because there is no read lock. It still can't modify it using any functions that require write access to the temporary database. What we lose is that the callback cannot call any "read-only" functions that use temporary tables because the step that requires a write lock will fail. -- Philip
