RE: SELECT FOR UPDATE
От | Glen Parker |
---|---|
Тема | RE: SELECT FOR UPDATE |
Дата | |
Msg-id | 014801c12bfb$342b4080$0b01a8c0@saturn обсуждение исходный текст |
Ответ на | Re: SELECT FOR UPDATE ("Oliver Elphick" <olly@lfix.co.uk>) |
Список | pgsql-general |
A 'document' may consist of several records from several tables, a relationship the DBMS doesn't understand. It also introduces alot of complexity. You may need a way to expire locks after a certain amount of time, or allow some users to override other users' locks. In a system I'm working on, I have a facility for both, and the expiration code works in two steps. At creation, the lock is 'mandatory' and can only be overridden by an admin user. After a day of inactivity against the lock, it becomes 'advisory', meaning that anyone can override it, but if it is not overidden it remains valid for the owner for one week, after which time it is removed altogether. Stuff like that is, IMHO, far beyond the scope of an SQL server. Glen Parker glenebob@nwlink.com > I prefer Jan's solution: on first attempt to change, acquire a user-level > lock by creating a lock record; if you can't get the lock, don't allow > any change. > > However, it would be convenient if the database would do this for me. I > still don't understand why people think it undesirable for it to > do so, since > it is a problem universal to multi-user databases and the effort is > therefore more economically spent at the database rather than at the > application level.
В списке pgsql-general по дате отправления: