In the main thread of our application there are numerous timers.

A timer can fire while the application is still transferring a result set (i.e. query A is open), and the timer can generate another query, query B.

Can query B use the same session as Query A, or must we create a new session for it?

jwtm wrote:

> Can query B use the same session as Query A, or must we create a new
> session for it?

I can't be positive on this, but I'd say create new, or delay the next
one until the first is finished.

--

Matthew Jones

jwtm

>In the main thread of our application there are numerous timers.
>
>A timer can fire while the application is still transferring a result set (i.e. query A is open), and the timer can generate another query, query B.
>
>Can query B use the same session as Query A, or must we create a new session for it?

There's no reason why not since the restriction on sessions is by thread not query. However, how Windows will go about scheduling the time slices is a mystery to me.You will probably find query A will have to finish before query B can start, but as I say I don't know.

Roy Lambert

Roy Lambert wrote:

jwtm

>In the main thread of our application there are numerous timers.
>
>A timer can fire while the application is still transferring a result set (i.e. query A is open), and the timer can generate another query, query B.
>
>Can query B use the same session as Query A, or must we create a new session for it?

-- There's no reason why not since the restriction on sessions is by thread not query. However, how Windows will go about scheduling the time slices is a mystery to me.You will probably find query A will have to finish before query B can start, but as I say I don't know.

Roy Lambert

Thanks for the reply, but unless I know for certain sure that a session can maintain multiple open queries (which other DBMSs can't) then it's going to be a separate session for each open query.

On 25/11/2014 12:31 p.m., jwtm wrote:
>
> Thanks for the reply, but unless I know for certain sure that a session can maintain multiple open queries (which other DBMSs can't) then it's going to be a separate session for each open query.
>

// (which other DBMSs can't)  Really?

Hi

You'll be making a lot of unnecessary work for yourself if you do have
multiple sessions.

I'm sure it isn't necessary.  I'm using DBISAM v3 (old thing) and EDB
and for both I have multiple queries open concurrently and all in one
session.

Apart from leaving queries open for later use, I have a timer that fires
off a query (looking for "Bring Ups" - like calendar events).

If there any rows in the query result, I pop up a reminder form with the
result set in a grid and a GUI that allows the user to edit the records.
 This has worked single session and single thread for 14+ years for the
BDE, DBISAM versions, and now EDB with no problems at all.

Cheers

Jeff

On 11/24/2014 1:19 AM, jwtm wrote:
> In the main thread of our application there are numerous timers.
> A timer can fire while the application is still transferring a result set (i.e. query A is open), and the timer can generate another query, query B.
> Can query B use the same session as Query A, or must we create a new session for it?

What does "application is still transferring a result set" exactly mean?

Simply having a query open is different than doing something with it.
EDB definitely allows you to have multiple queries open but since you're
on the main thread only one thing can run at the time so if you're for
example processing a query resultset in a tight loop then nothing else
will run until you finish (including timers since those are just windows
messages) or yield.

Is this local or remote connection (edb server) ?

Remote connection might behave slightly different due to paging that
takes place so it might yield but then again edb server has a thread per
connection so if that is busy then you might have an issue.

In general having separate sessions is better approach but be aware that
you might lock up your UI or app depending on your design here.

Raul

Raul wrote:

On 11/24/2014 1:19 AM, jwtm wrote:
> In the main thread of our application there are numerous timers.
> A timer can fire while the application is still transferring a result set (i.e. query A is open), and the timer can generate another query, query B.
> Can query B use the same session as Query A, or must we create a new session for it?

-- What does "application is still transferring a result set" exactly mean?

The Elevate server transfers result sets in chunks, N rows to a chunk (probably. I don't think it transfers partial rows) At some point when your program is iterating through rows, the client engine fetches the next chunk.

Simply having a query open is different than doing something with it.
EDB definitely allows you to have multiple queries open but since you're
on the main thread only one thing can run at the time so if you're for
example processing a query resultset in a tight loop then nothing else
will run until you finish (including timers since those are just windows
messages) or yield.

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.

--In general having separate sessions is better approach but be aware that
you might lock up your UI or app depending on your design here.

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.

Bill.

Raul

jwtm

>Thanks for the reply, but unless I know for certain sure that a session can maintain multiple open queries (which other DBMSs can't) then it's going to be a separate session for each open query.

Both Raul and Geoff have expanded on my reply but another thought crossed my mind which could well render your question meaningless. What sort of timers are you using?

If they're standard TTimers then I doubt that the timer will even fire before query A is complete and Windows can process messages again.

Should you want to run queries simultaneously you'll have to use multiple threads and work out a mechanism for returning the result set back to the main thread.

Roy Lambert

jwtm


>The Elevate server transfers result sets in chunks, N rows to a chunk (probably. I don't think it transfers partial rows) At some point when your program is iterating through rows, the client engine fetches the next chunk.

There is absolutely no problem with that. Its what ElevateDB (and DBISAM before it) is designed to do.

>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.
>
>--In general having separate sessions is better approach but be aware that
>you might lock up your UI or app depending on your design here.
>
>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.

You only need separate sessions etc if you're running things in a separate thread. ALL activity within a single thread can go through a single session and it will sort it out.

You seem to be asking a slightly different question here. Separate threads require full isolation to effectively prevent memory clashes which in turn can lead to database corruption. Within a single thread the TEDBSession and TEDBEngine manage all of that for you.

As I said in my previous post exactly when things will run depends to a large degree on how Windows allocates timeslices and responds to messages, however, there is no need to worry about data clashes/corruption.

Unless they are needed for other reasons just use one session per thread. Every time you create a separate session you're giving the server another thing to manage which will need its own timeslice of attention which will slow things down (ever so slightly), but as you've noticed all the session creation and login activity takes time.

You don't even need to worry about timers firing because they will only do that when Windows allows and at that point ElevateDB will handle things.

Being very nosey why do you have lots of timers on a form?

Roy Lambert

Roy Lambert wrote:

> If they're standard TTimers then I doubt that the timer will even
> fire before query A is complete and Windows can process messages
> again.

Never assume a timer can't fire twice. Not only is the
Application.ProcessMessages able to do this, but Windows itself does
it. I fell over big time back in 1988 with this assumption in an
application, when I discovered that the main thread was re-entrant if
you do file I/O.

However, this is easy to fix:

procedure OnMyTimer(Sender : TObject);
begin
 if m_bInTimer then
   exit;
 try
    m_bInTimer := true;

    DoStuff;
 finally
   m_bInTimer := false;
 end;
end;

This ensures that the particular code related to that timer won't work
on the same objects again (and again) if something takes more than the
timer duration. So long as the queries are not the same as other UI
queries that may be happening, then all will be well.

--

Matthew Jones