Re[2]: [Firebird-devel] Max transaction duration

[Nickolay S. <sk...@bs...>]

Hello, All !

Friday, December 13, 2002, 3:54:20 PM, you wrote:

Allowing long-running transactions to kill database operation is
actually a security problem because user essentially without rights
can kill database operation.

Oracle and MSSQL solve this problem by allowing to define several
limits for roles (with database and server-wide default) like maximum
transaction duration, CPU time per query, etc. Maximum duration of
serializable transaction in Oracle is limited by the size of undo
tablespace (where record back versions are stored).

Current Firebird implemenation is insecure. You can kill the server
by passing invalid handle to it or to execute whatever you need
binary code on the server side tweaking with handles of deleted
objects or using one of the known buffer overflows.

My opinion on this issue is that it should go to security issues queue
and we should make a feature to prevent DOS-attacks by starting
transactions, but its priority in this queue should not be too high.

> Hi,

> I have been following this thread, and I think there is a 'bluring' between 
> Connections and Transactions.

> When a 'Client' crashes, or the LAN cable is pulled out etc, Firebird will 
> (eventually) notice, close the connection and rollback any open transactions.

> Why people are so passinate about transactions is because they can be a major 
> cause of performance and other issues with FB.

> The majority of performance problems on the lists/newsgroups are down to 
> 'incorrect' use of transactions.  Long running transactions are not a good 
> thing in FB, and whilst sometimes they can't be avoided (end of month batch 
> runs etc.), the majority can.

> The problem is most evident when people move to FB from 'other databases', 
> and the first app they write starts a transaction in the morning and they 
> fill an 'editable grid' with data, and then wonder why the whole system has 
> ground to a halt by lunch.

> In my opinion, in a properly designed system, transactions should only be 
> open when reading or writing to the database.  So I see no reason at all to 
> have 'transaction timeouts', as if a transaction is open, something is being 
> written to, or read from the database, and any time out will abort the 
> operation.


> Phil

-- 
Best regards,
 Nickolay Samofatov                        mailto:sk...@bs...