> 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.
But transactions are supposed to occur very quickly.
> 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.
In this case, I would use webDAV, not a RDBMS, unless I needed
relations between the documents that I couldn't get by simply using a
directory structure.
> So, the lock table would need a time-out field, and might also
> include a queue of people waiting for the record.
Yes, this is what confuses me most about Jan's post. The lock table
functionally resides between the RDMBS and the application/user, and
in doing so it defeats the purpose of an RDBMS. What should I use
triggers, rules, and listen/notify for then? I guess LISTEN/NOTIFY
could be used in conjunction with the lock table.
> 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....
Exactly, your not making a database, and as for the hybrid... This is
why XML is such overhyped shit right now, nobody likes/trusts RDBMS's.
