On Wed, 27 Mar 2002, Jan Wieck wrote:
> Hal Davison wrote:
> >
> > In an operational sense, if a user is updating a table for some accounting
> > function then decides to go to lunch leaving the table locked.
>
> Exactly what I expected. You have a severe design flaw in
> your application. Database transactions have to be short and
> never held over actions that could infinitely block, such as
> user interaction, period!
>
> You need application level advisory locks. The abuse of
> database locks for that will not get you very far. Your
> application will not scale and suffer from problems like the
> one you already face.
>
> Ever thought about adding a WEB interface to that
> application? If a user editing some account needs to hold a
> DB lock all the time, you'll not implement it with
> Apache/PHP, that's for sure already. And you'll have to make
> alot of painfull pushups to do it with any other WEB server
> technology.
>
>
> Jan
Jan,
I don't have this problem. A request was issued for an possible example as
to WHY someone would need to determine who has a table locked.
I am quite aware of the implications of table as well as row locking in a
production situation.
--Hal.
