[Firebird-devel] Re: Max transaction duration

[Juarez R. <ju...@mp...>]

I see 3 types of problem here:

1) The political :
When the user discover a interactive tool. Solution : Just buy a gun and
kill him.

2) The most political :
You need give different power for users. if Joe works on reception and want
find 'Mary' in all database he will waste resources from others users. The
problem is where the developer cannot guess the time involved, so give him
one minute. But if Jim must show for 'Bill' the end-of-year report, he
cannot be simply stopped.
Finally this dicussion will go to features 'kill' and 'nice' implemented.

3) The login model.
Really there are more than one need for a database. Monouser applications
and webservers dificultly need a login. And in the second case login can be
a performance penalty in a web context.

----- Original Message -----
From: "Ann W. Harrison" <aha...@ib...>
To: "Juarez Rudsatz" <ju...@mp...>;
<fir...@li...>
Sent: Thursday, December 12, 2002 12:58 PM
Subject: Re: [Firebird-devel] Re: Max transaction duration


At 07:01 PM 12/11/2002 -0300, Juarez Rudsatz wrote:
>- Default duration defined at user level to be able to override the
server's
>default configuration.

If the problem is users who discover an interactive query
tool and leave transactions open for days, then requiring
that the user transaction limit itself is probably not going
to work.

>Here's one way of designing it:
>- Default duration defined at the server level, so when creating a new
>database it will use that default duration.

That bothers me somewhat, probably because I'm not entirely
happy with the server model starting with server logins.  Yes,
sometimes a single machine will host a number of related databases.
More often, just a single database.  And sometimes, a number of
unrelated databases.  That case really can't be supported now.


>- Default duration defined at the database level
>- Pass the duration upon connection
>
>I know that this might require some changes to the API.

Actually that can all be done with connection and transaction
parameters - yes, we'd need to add parameters, but that doesn't
fundamentally change the API


Regards,

Ann
www.ibphoenix.com
We have answers.