Posted by Gordon Burditt on 05/19/06 23:59

>If your database brand (I am not familiar with postgress) does not
>support transactions or locking, you can invent your own. With a

Web-based transactions that require user interaction in the middle
of them are dangerous and pretty much useless. Part of the problem
is that there is no timeout value which is not too short, too long,
or both at the same time. In a tech support or customer service
environment, where techs edit customer records, consider the
possibilities for getting fired or murdered by co-workers if your
computer crashes in the middle of an edit and delays the daily
billing run.

>timestamp field and a user (or sessionId) field, you can see what user
>has requested a lock. If it is locked too long ago, it is free. If it is
>locked by another user or session, it is locked. As SQL commands are
>usually atomic (I have yet to encounter a database brand that has unsafe
>commands), an update command can be forged that takes the full locking
>condition in its WHERE clause.

>Look up the section about transactions in the database's documentation.
>The fear of "hanging" open transactions is often solved by the fact that
>connections are reset by PHP after executing the script, and the

In other words, in a PHP-based setup, the transaction is reset
before the user has a chance to answer the "are you sure?" prompt.
(Note to self: never permit creation of a user by the name of
"sure"). Net effect: they're useless since the transaction is
always rolled back.

>database rolls back any open transactions in a connection when it is
>reset/closed. Again, I do not know how Postgress handles transactions
>and connections.

Gordon L. Burditt

[Back to original message]