Matthew

I've just thought of the sheer mess that a re-entrant timer could cause if you create a separate session/database/query in each firing <VBG>

However, useful though the reminder is, that's a different question to the one being discussed here.


Just for interest usually the first line in one of my timers is

Timerxxx.Enabled := False;

with a final line of

Timerxxx.Enabled := True;

if I want it to fire again.

Your approach would allow you to manage multiple timers simultaneously whereas mine doesn't.

I've also started to use multimedia timers for anything using display so that its not affected (or at least not as much) by message blocking.


Roy Lambert

Roy Lambert wrote:

> Timerxxx.Enabled := False;
> Timerxxx.Enabled := True;

Your way works fine too of course.


Matthew Jones

Bill,

On 11/25/2014 3:07 AM, jwtm wrote:
> Not necessarily true. Even in a tight loop, fetching the next chunk causes a network operation, which is asynchronous. In many systems, such operations are carried out in a communications thread; while this communications thread is waiting for a response, the main thread is free to service messages, which can include timer events. Now I don't know if the Elevate client engine does this; I just know it can do and it's rather common. Hence the question.

EDB is designed to be blocking which makes the system very easy to
program and very predictable from debugging perspective. Unless you
yield the processing yourself in some way (ui operation or
straightforward yield) ) consider EDB to be blocking (even over network
retrieval).

Since this is remote session you also have the edb server to consider
which as i mentioned allocates a thread per connection so you might have
an issue there (I haven't tested this specific scenario as you outlined
since we try to avoid them).


> Unnecessary sessions mean unnecessary logins, which take time. In the application I am trying to improve, 40% of query service time is consumed with login session and open database messages, most of which are unnecessary. So I am trying to get the real, hard rules about what can and cannot be done with sessions.

It's difficulty to advise without knowing more but single session is
definitely very shareable - few of our apps have 5+ queries open
concurrently against the same session almost all the time (and a few
tables). All of those are used for short operations (fetch small dataset
etc) so blocking is minimum. We do use timers but in a non re-entrant
manner.

All our heavy lifting queries and tables (ones that actually take time)
have been moved to a separate threads where again they get s single
session.

In all cases session is opened once and remains open and only
queries/tables get closed/reopened.

Raul

Bill,

On 11/25/2014 8:59 AM, Raul wrote:
> Since this is remote session you also have the edb server to consider
> which as i mentioned allocates a thread per connection so you might have
> an issue there (I haven't tested this specific scenario as you outlined
> since we try to avoid them).

I got curious so ran a quick test and this part works just fine - i can
open and iterate thru a 2nd query resultset while 1st one is looping
thru its resultset still (in this case the 2nd query processing was
called from inside the loop of the 1st one as well as from a separate
timer but i had to call Application.ProcessMessages to yield - i know
something i would never do in real code).

hence sharing session part should be all fine.

The main issue you will have will be around the timers and will they
fire and if not whether you need to manually yield which itself might
lead to bugs and of course the overall main thread and UI getting
blocked if you have long-running query operations.

Raul

--Roy Lambert wrote:
--Being very nosey why do you have lots of timers on a form?
--Roy Lambert

It's a legacy app. All I'm doing is trying to speed it up with minimal changes to what's there.

Bill.