Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 11 to 15 of 15 total |
Session sharing with timers |
Tue, Nov 25 2014 4:51 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Tue, Nov 25 2014 4:59 AM | Permanent Link |
Matthew Jones | Roy Lambert wrote:
> Timerxxx.Enabled := False; > Timerxxx.Enabled := True; Your way works fine too of course. Matthew Jones |
Tue, Nov 25 2014 8:59 AM | Permanent Link |
Raul Team Elevate | 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 |
Tue, Nov 25 2014 9:22 AM | Permanent Link |
Raul Team Elevate | 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 |
Tue, Nov 25 2014 4:31 PM | Permanent Link |
jwtm | --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. |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Thursday, May 23, 2024 at 07:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |