19.02.2017 5:21, Leyne, Sean wrote:
>
>
>>> If I read the documentation correctly, a statement which performed
>>> (say) a SELECT against a table that
>> > follows a NATURAL scan, which is 'paused' awaiting the next Fetch, would
>> run into the timeout, even > though there is no "cost" to the engine of
>> waiting.
>>>
>>> Am I correct?
>>
>> Yes.
>
> That doesn't seem quite right.
>
> I always think of Timeout as been a measure of the amount of time the engine
> is busy/working.
Here i not agree with you. Typical use cases is enlisted in docs. More, what
you describe above
will not work at all in concurrent environment as it is close to impossible to
measure exact time
when engine working on *given* statement. Also, such measurements could have
its own cost and add
overhead.
> Otherwise, why would "milli-second" based Timeout value have any use.
Users asks for milliseconds and it is technically possible.
> While waiting for a "fetch" the engine is doing "nothing", so IMO, it should
> not factor into the timeout.
Just one sample: you offer to exclude time between API calls but what about
time spend on thread
context switch, IO wait, lock\latch wait and so on ? Engine doesn't work in
such moments, isn't it ?
Please, think on statement execution timeouts from client app POV.
> {I have done some searches on how other engines handle this issue but haven't
> not found any good details/examples}
Believe me, i also searched for this info and nobody did it in a way as you
think above.
>>> Separately, it would be "a good thing" if the Timeouts could be set in
>>> Trigger or SP -- perhaps via
>> > special "SQL_Timeout" RDB$Context for the "User_Session" and
>> "User_Transaction" namespaces.
>>
>> For what goal ?
>
> To allow for the timeout to be customized.
There is already a ways to customize timeouts.
> Arguably, setting the "SQL_Timeout" value in the > "User_Transaction"
> namespace would allow the
> timeout value for the *current transaction* to be overridden in code,
> without the need for API
> settings.
There is no such thing as "timeout for transaction". Stmt execution timeouts
could be set at
database (config), connection and\or given statement level.
> Similarly, for the "User_Session",
Seems you missed SET STATEMENT TIMEOUT statement
> which would, of-course, apply to the next transactions of thecurrent
> session/connection.
Probably you mixed "statement execution timeout" with "lock timeout". "lock
timeout" could be
set at transaction level, yes, but it have no direct relation with "statement
execution timeout".
Regards,
Vlad
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
