Re: How to handle mouse events during a long-running database transaction?

On Sep 15, 8:19 pm, "tom.rmadilo" <tom.rmad...@xxxxxxxxx> wrote:
On Sep 15, 9:54 am, Teemu Salmivesi <salmiv...@xxxxxxxxx> wrote:



On 15 syys, 15:04, Alexandre Ferrieux <alexandre.ferri...@xxxxxxxxx>
wrote:

On Sep 15, 1:30 pm, Teemu Salmivesi <salmiv...@xxxxxxxxx> wrote:

We have a very large application which is not planned to use threads
and it is not thread safe.

Then look at the contradiction in full light: either you manage to
isolate your blocking transaction in another thread, or you'll have to
do the finer-grained scheduling by hand (assuming you can split one
long wait into several shorter-timeout operations). No way out.

I agree.
The application includes c and c++ code about 5.000.000 lines.
That means that an another thread is not easy to implement because the
code is not thread safe as I mentioned earlier.
The application has TCP/IP, UDP/IP connections, local memory database
and the GUI.
I know that the design of the application is not the best one,
but the code is very efficient except the huge task which will update
the local database thru the TCP/IP connection.

We are planning to do scheduling by hand. Our plan is to interrupt the
long running task (not always a db transaction) and
handle mouse events so often that response of the GUI will be good
enough. I know that there is a possibility to handle collapsed mouse
events in Tcl
but I don't know how to do it inside the TCL_DoOneEvent function. It
seems that we are not able to get mouse motion events at all.
Do you have any idea how to get mouse motion events from the event
queue of Tcl?

- Teemu

Note that isolating your database part in a separate *process*, if the
needed I/O bandwidth permits, will save you the hassle of making
anything thread-safe. It will morph the problem into one of
serialization, which is way simpler.

Why not update the GUI via tcp/ip or udp? Usually a GUI is only a
snapshot of the actual state (especially if you are using a database),
so just decouple the GUI by using either a client poll or server
push.

Or maybe what you are saying is that your application makes a local
copy of the data and then uses a long transaction to update the real
database. If that is the case, the design issue is trying to
synchronize two copies of essentially one chunk of data. That is risky
and difficult. But if that is what is happening, you could make a copy
of the data from your GUI application and then run an update from the
copy (a headless version of your application) to the database, kind of
like an auto-save feature, but it could avoid a GUI freeze (the exact
same thing happens with your typical desktop application during an
auto-save operation).

The application is handling the task received from TCP/IP (socket) and
updating the local database.
At the same time user is drawing something eg. free draw on a canvas.
Sure we have to catch all mouse motion events to show the drawing
correctly.
We are using Tcl event queues to update data from the socket and we
are using Tcl queues to handle all mouse events.
But we are not able to get mouse events if we are already inside the
TCL_DoOneEvent function.
It is possible to call TCL_DoOneEvent recursively, but how we are able
to handle mouse motion events only?

- Teemu
.

Relevant Pages

  • Re: How to handle mouse events during a long-running database transaction?
    ... isolate your blocking transaction in another thread, ... code is not thread safe as I mentioned earlier. ... The application has TCP/IP, UDP/IP connections, local memory database ... and the GUI. ...
    (comp.lang.tcl)
  • Re: How to handle mouse events during a long-running database transaction?
    ... isolate your blocking transaction in another thread, ... code is not thread safe as I mentioned earlier. ... The application has TCP/IP, UDP/IP connections, local memory database ... Do you have any idea how to get mouse motion events from the event ...
    (comp.lang.tcl)
  • Re: How to handle mouse events during a long-running database transaction?
    ... isolate your blocking transaction in another thread, ... code is not thread safe as I mentioned earlier. ... The application has TCP/IP, UDP/IP connections, local memory database ... and the GUI. ...
    (comp.lang.tcl)
  • Re: How to handle mouse events during a long-running database transaction?
    ... isolate your blocking transaction in another thread, ... do the finer-grained scheduling by hand (assuming you can split one ... The application has TCP/IP, UDP/IP connections, local memory database ... and the GUI. ...
    (comp.lang.tcl)
  • Re: Concurrency problem
    ... I did not make much attention that you was using a transaction. ... A transaction is in my idea something that should be avoided as much as possible, because it can lock your tables unwished completely ... My problem is that while the baych application is updating the database, the GUI application gets locked out. ... Question is what properties do I need to set on the Connection/Command objects to let the GUI ignore the locks and access the data anyway? ...
    (microsoft.public.dotnet.framework.adonet)