On 26 Aug 2001 13:50:16 -0700, Cody <[EMAIL PROTECTED]> wrote:
> I just finished reading Bruce M's book, so this thread confuses me,
> esp. Jan's posts. I take full heed of the need for application level
> user/thread management, but I was interested in using a parallel
> set-up in PG (however redundant that might be). Now that Jan has
> discounted "SELECT...FOR UPDATE," is the best alternative using a
> central locking table (perhaps in conjunction with LISTEN & NOTIFY)?
> Ironically, anyone who suggested using application level transactions
> would be torn apart at any of the places I've worked at--but that
> seems to be the gist of this thread. I cannot see a way to avoid
> deadlocks without an application level transaction component, since
> the central locking table idea would similarily lock the record
> forever if the first transaction failed to COMMIT or ROLLBACK.
>
> What is the saying: To the beginner, there are many options. To the
> wise, there are few.
It seems to me that SELECT ... FOR UPDATE is not the way to go if
it is possible that the selected record may be held for any length
of time.
The best way around this is going to depend on the application and
resolution of conflicts will probably take place in the application.
For instance, say you are storing web pages in the database, and you
want a number of developers to be able to get pages from the database
look at them, and possibly make changes and update the record.
Your application might have some kind of sliding time-out scale from
a 3-minute "I see a typo" to a 30-minute "This really needs work".
It would probably also remind the author before the time-out or
possibly automatically save and re-acquire the lock if possible.
So, the lock table would need a time-out field, and might also
include a queue of people waiting for the record.
This is just how I was thinking of it, and again I think it will
depend on the application. At some point, you're not making a
database, you're creating a cvs. Though a hybrid could be good....
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
