For Stene, or anyone who can answer his statements
it a fantastic design pattern and don’t dismiss them too easily.
they are NOT for long running operations, although you can use them for that.
the answer is far more simple than that.
They allow ASYNCRONOUS access to the database rather that the normal access with is SYNCHRONOUS and BLOCKING.
on the technical side, omnis runs everything in thread 0 — which is the GUI thread.
if you do a SQL call in the GUI thread, then the GUI cannot respond for the amount of time that the SQL statement is sending, waiting and retrieving data.
to the end user, that means beachball because the data is being retrieved SYNCHRONOUSLY
if you introduce a GUI widget on your screen like a tab pane (for example)
and if each tab pane could be filled with a bunch of data
then you could lock up the GUI and make the user think your application is broken, because they don’t like to wait any more
IF, on the other hand, you loaded the data in background threads for these tabs, then the use could click all over the place while the data is loading an it seems like the application is responsive.
Why, because the data is being loaded ASYNCRONOUSLY in other threads so the gui thread stays responsive.
when we showed this concept at Euromnis about 6 years ago, our demo was to load up 50 separate windows with a few thousand rows of data all at the same time and keep on moving the windows around as data was loading nicely in the background.
its a very handy feature . so we use it as a design element for about 70$ of our windows where we know there is lots of data.
The benefit is even more pronounced when the data is miles away on the cloud — since the latency is all about how long it takes for data to get there.
if you design your application right, you can have it switch between background and GUI thread as you need.
see you at the third annual users conference
> On Jan 25, 2018, at 6:52 PM, Das Goravani <email@example.com> wrote:
> In my understanding SQL workers are only necessary if you have long running SQL operations and session pools are only necessary if you want to use more than one session at a time, am I correct?
Manage your list subscriptions at lists.omnis-dev.com