Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timeout parameters [CORE985] #1392

Closed
firebird-issue-importer opened this issue Oct 31, 2006 · 15 comments
Closed

Timeout parameters [CORE985] #1392

firebird-issue-importer opened this issue Oct 31, 2006 · 15 comments

Comments

@firebird-issue-importer

Submitted by: ohenri (ohenri)

Is related to CORE658
Relate to CORE4238
Jira_subtask_outward CORE5466
Is replaced by CORE5488

Votes: 3

Actually the two paramters "ConnectionTimeout" and "DummyPacketInterval" do not fit all requirements, and "DummyPacketInterval" seems not to work in 2.0 as it does 1.5.3.

I suggest to change the managament of such things as follows.

Timeout parameters, basically stored in the conf file:

- ConnectionTimeout - same as today.

- Command Timeout - new - does specify how long a command may run until it is cancelled (and naturally rolled back) by the engine itself.

- Transaction Timeout - new - does specify how long a transaction may be open until it is rolled back by the engine itself.

- Idle Timeout - new - does specify the time to wait until a silent (no running commands) connection is dropped.

CommandTimeout, TransactionTimout and IdleTimeout shall be changeable from the client for the own connection (before a long running task, for example).

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 28, 2008

Modified by: @pcisar

Workflow: jira [ 11296 ] => Firebird [ 15329 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Oct 22, 2008

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Oct 19, 2009

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Oct 19, 2009

Modified by: @dyemanov

Link: This issue is related to CORE658 [ CORE658 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Oct 23, 2012

Modified by: @dyemanov

Fix Version: 3.0 Beta 1 [ 10332 ]

Fix Version: 3.0 Alpha 1 [ 10331 ] =>

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Oct 8, 2013

Modified by: Sean Leyne (seanleyne)

Link: This issue relate to CORE4238 [ CORE4238 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 18, 2014

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ] => Vlad Khorsun [ hvlad ]

Fix Version: 3.0 Beta 1 [ 10332 ] =>

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 9, 2016

Modified by: @dyemanov

Fix Version: 4.0 Alpha 1 [ 10731 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 22, 2017

Commented by: PizzaProgram Ltd. (szakilaci)

This is THE feature we are waiting for since FB1.0 :)
but not only for long running tasks.

The Timeout parameters should be in milliseconds (int64)* please.
-1 = infinite (<0)
0 = no timeout
<50 = there can be an auto-minimum inside the engine : if (t<50) then t:=50; // maybe 20ms is enough too, needs testing
<1000ms = it is sometimes necessary to control short-running transactions. ex.: should be finished within 100ms ... otherwise something is wrong with server/connection/etc ... and need to deal with it differently on the app. side.

* or we could use DOUBLE. (0.5 = half sec.)

Would be nice, if

AUTONOMOUS TRANSACTION would have a TIMEOUT parameter too.
or EXECUTE STATEMENT ON EXTERNAL DATA SOURCE would have a CommandTimeout.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 22, 2017

Commented by: PizzaProgram Ltd. (szakilaci)

A possible implementation for this:

1.) There would be a LinkedList* resident in the memory of the FB engine:
<event_type : byte> -- {1=connection | 2=transaction | 3=command ... ? }
<event_id : bigint> -- {the conn or trans ... ID}
<event_ends : timestamp> -- when it should be timed out.
* see more about: http://stackoverflow.com/a/270094

2.) This List would be sorted/indexed by <event_ends> value. (Ascending)
- every time a new event is started, AND IT HAS a TIMEOUT parameter too >>
it's ID would be inserted into this list. (Keeping the time-order.)

3.) It's enough always to check the beginning of this list, if the first item in the list is past current time.
- delete that Item from the beginning of that List.
- check if that event still exists .
- Signal the event it should stop executing and should drop a timeout exeption.
"stop_because_of_timeout = True" (Booleans are multi-thread-safe and fast. )
- the event itself (for example a running query) checks that boolean periodically.
- check next ListItem.

4.) This check would run every 50ms once.
- It is not a problem, if the engine does not immediately recognize: the event timed out.
- Basically extra 49ms delay is still fine. If the event finished by itself by than, even better :)

5.) Commands would look like this:
SELECT TIMEOUT(5000) * FROM invoice_details WHERE recorded > '2000.01.01' ;

... Maybe the format "WITH TIMEOUT" would be more elegant... also WITH LOCK WITH TIMEOUT()

6.) By a connection-timeout method even a Backup could be time-maximized!

7.) Hierarchy:
- if the is no "timeout" in [firebird.conf] nor [TPB] nor at the [SQL] >>> nothing happens = standard behaviour
- overwrite order:
[firebird.conf] <<< [DB connection TPB] <<< [TRansaction TPB] <<< [Command SQL]

8.) I'm not sure if [Connection Idle Timeout] is necessary. I'm afraid it would cause more harm than good.
(For example a simple Delphi program with 1 DB component expects: a local DB should be open forever until closed ... even if I put a laptop to sleep for a month.)

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 22, 2017

Commented by: PizzaProgram Ltd. (szakilaci)

There should be 3x3 different error codes for each of these timeout-kinds:

timeout_db_def <Database connection timeout set in config file @1 ms>
timeout_db_tpb <Database connection timeout set in API TPB @1 ms>
timeout_db_cmd <External database connection timeout set in SQL @1 ms>

timeout_tr_def <A rollback performed by transaction timeout, set in config file @1 ms>
timeout_tr_tpb <A rollback performed by transaction timeout, set in API TPB @1 ms>
timeout_tr_cmd <Autonomous transaction timeout, set in SQL @1 ms>

timeout_sql_def <SQL command timeout, set in config file @1 ms>
timeout_sql_tpb <SQL command timeout, set in API TPB @1 ms>
timeout_sql_cmd <SQL command timeout @1 ms>

... so a developers can see the difference. (Much easier to test and debug.)

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 22, 2017

Commented by: @hvlad

The feature is almost finished and already committed into separate branch (for review and testing).

You may found it there
https://github.com/FirebirdSQL/firebird/tree/timeouts

It lacks documentation so far, the more-or-less close description could be found there
https://sourceforge.net/p/firebird/mailman/message/35285574/

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Feb 22, 2017

Modified by: @hvlad

Link: This issue is replaced by CORE5488 [ CORE5488 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Feb 22, 2017

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Duplicate [ 3 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Feb 22, 2017

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants