On 12/17/2004 1:10 PM, Greg Stark wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>
>> As said, open transactions with DB locks during user interaction are a known
>> bad idea for every sort of application. That together with the scaling problems
>> is IMHO reason enough not to implement something that is designed to avoid
>> proper application side advisory locks.
>
> I think it's a higher level divergence of opinion here. What he's talking
> about is more like the Java/J2EE approach of building lots of infrastructure
> to make everything work magically. Our instincts are to keep things simple and
> avoid big hammers for features that would be hard to manage.
ANSI SQL doesn't specify any lock timeouts or possibility to cancel
someone elses transaction, heck it doesn't even define any way to find
out what particular lock is held by what session. Maybe a database
system that is oriented towards standard conformance isn't the right
choice for this environment.
Standard conformant SQL databases do not work well with open
transactions holding locks during user interactions. That is a fact. I
would object to adding proprietary features to PostgreSQL so that the
application developer can use some sort of SQL looking gibberish instead
of creating the appropriate framework. I am however only one developer,
and if other key members of the developer community are in favor for it,
I can certainly ignore such feature - given it wouldn't affect the rest
of PostgreSQL's features or performance as long as not used.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #