1. Could you perhaps edit individual rows instead of the whole table.
2. If you use persistant connections ala Apache::DBI you may not get back to the same child you talked to when you were
lockingso somebody doing something else would get the locked connection.
3. You could make som sort of named connection jumping through hoops - hook up to a client via a named pipe which again
isconnected to the database server, and storing a cookie or similar to connect to that particular named pipe - Highly
unrecommended.
4. You could create a virtual locking table which says what table is locked by who, before allowing a new virtual lock,
anyclient would check with that table.
5. Any kind of locking is often undesirable. remember postgresql supports mvcc!!
Regards,
Aasmund
On Tue, 23 Oct 2001 10:08:23 -0700, Dado Feigenblatt <dado@wildbrain.com> wrote:
> Hi, I'm fairly new to this subject.
>
> How does locking work when accessing the database via web interfaces?
> Usually applications work in a browsing mode. When you click the edit
> button, the same data is presented in a form which can be submited for
> update.
> Is that necessary? If we don't consider the security problems of being
> in 'edit mode' all the time, do we need to keep switching between modes?
> And what I really want to know is that being web interfaces stateless,
> whatever builtin locking you implement it will drop as soon as the web
> server is done.
> Would persistent connections fix this? Do people use this mode switching
> to implement their own locks?
>
> Any pointers to literature on this?
>
> Thanks.
>
> PS: Should I send this to SQL? Whats the policy on cross-posting?
>
> --
> Dado Feigenblatt Wild Brain, Inc.
> Technical Director (415) 216-2053
> dado@wildbrain.com San Francisco, CA.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
Aasmund Midttun Godal
aasmund@godal.com - http://www.godal.com/
+47 40 45 20 46
