|
Would be nice if you explain more about what kind of problem you
want to solve. There are two main questions "to solve" a) generally speaking, I like to get some form of "exclusive access" to the row before updating or deleting. None of the optimistic / pesimistic automatic variants of concurrency management glad me. Nor, of course, the "versioning" variants. b) some of the tables I´m working on have a "number" column (not the PK) which sometimes come from material, external sources, but sometimes must be assigned by the system. This could be solved two main ways b.1) Use a trigger to get the famous "max(n) + 1". At least in one of the cases, the number automatically generated must fall into different ranges conditioned by the value of another column, and the ranges vary between versions of the database. b.2) "Lock the entire table", get programmatically the next number for the correct range, assign it and free the table lock. Of course, and beforehand, all database manipulations are done thru applications. Till yesterday, I was working with the "advisory" family. Having a bigint as the only "lock identifier" I was working with a hash of the table name XORed with the id of the row or zero for the entire table. (All my tables have an autosequential integer id as PK). Even if I found a very robust hash algorithm for the table name, I cannot discard some collision once the id was xored. I tested five or six table names, along 20000 ids every one, without collision. But... Of course, I need the "full table lock" for inserts. So, it´s a very separated concern with updates and deletions. But... TIA On 17/09/2018 03:19 , Fabrízio de Royes
Mello wrote:
|
