Hi,
Our Goal:
On the client side, events on the bus should be processed one at a
time by their handler, in order, FIFO.
Details:
Just took over a pretty involved GWT/Spring/Hibernate/Gilead system.
App
works great; it is super fast, snappy, and responsive. One problem
sitting
in the backlog, though, results from the fact that some single-
threaded
server side code is entered by multiple threads working on the same
piece
of data. End result is that the data gets stomped on. When we add
uniqueness constraints we see that a duplicate key exception is
occurring,
so we know something is happening that should not.
>From a user perspective, this should never happen, because they
move along on their way using the app, clicking on things, in
sequence,
and that sequence makes sense, and in doing so it adds events to the
event bus... basically EVT_A -> EVT_B -> EVT_C -> ... and so on. EVT_A
handling should complete before EVT_B handling and EVT_B handling
should
complete before EVT_C handling and so on and so forth.
In practice a problem manifests though, because on the client side the
handlers all fire off right away (as one would expect) resulting in
multiple threads computing against the same data in the same place.
Here
is how it looks:
TIMESTEP 1
EVT_A (DATA_COPY_1) -> HDL_A -> SVR_CALL ->
compute_method(DATA_COPY_1)
EVT_B (DATA_COPY_2) -> HDL_B -> SVR_CALL ->
compute_method(DATA_COPY_2)
EVT_C (DATA_COPY_3) -> HDL_C -> SVR_CALL ->
compute_method(DATA_COPY_3)
On the server side, multiple threads (coming from the handler servlet)
end up entering compute_method at the same time, and behold, things
blow up.
So, our desired behavior is that for certain paths of work, we want
sequencing. Looking at the app further, we decided that rather than
track
down all of the unique flows, that instead the entire app should
behave such that EVT_* are handled in order, period. This makes sense
from
a user perspective, and by following a blanket-approach we could force
the
entire app to just "do the right thing" so to speak. The above would
look
more like this where queue is the event bus and handler code executing
is all of the work no matter client-side presenter or server side that
it
takes to satisfy the goal for that event:
TIMESTEP 1
QUEUE {empty} HANDLER_CODE_EXECUTING{none}
TIMESTEP 2
QUEUE{EVT_A} HANDLER_CODE_EXECUTING{none}
TIMESTEP 3
QUEUE{EVT_B} HANDLER_CODE_EXECUTING{EVT_A}
TIMESTEP 4
QUEUE{EVT_C:EVT_B} HANDLER_CODE_EXECUTING{EVT_A}
TIMESTEP 5
QUEUE{EVT_C:EVT_B} HANDLER_CODE_EXECUTING{none}
TIMESTEP 6
QUEUE{EVT_C} HANDLER_CODE_EXECUTING{EVT_B}
TIMESTEP 7
QUEUE{EVT_C} HANDLER_CODE_EXECUTING{none}
TIMESTEP 8
QUEUE{empty} HANDLER_CODE_EXECUTING{EVT_C}
TIMESTEP 9
QUEUE{empty} HANDLER_CODE_EXECUTING{none}
Talking more we looked at client-side vs. server-side to make this
change.
We felt like queuing up all requests on the client side would have the
benefit of being real-Java, but the downside is that queueing up
threads
seems to go against the spirit and architecture of the server itself
(Tomcat).
Client side seems like equal amount of work, but we have the added
benefit
of not having to worry about out-of-order client requests and so on.
At this
point we plan to make the change on the client side. One option we
decided
against was using the UI to block the user from doing things out of
sequence
or before they should be doing them, and if we had been able to do
this
from the start we would have, but at this point feel that adding the
global
queuing would be much less work than identifying all of the code paths
that can result in out-of-order-execution-errors.
Our goal: on the client side, events should be processed one at a time
by
their handler, in order, FIFO.
Not sure of the approach yet, haven't dug in deep. Curious to know
what you
think about this problem we are facing, our proposed solution, what is
the standard GWT way to manage this, and how you might do it.
While this feels like a big change, gotta imagine that our situation
is not
totally unique because indeed sometimes you need sequencing.
Look forward to your thoughts and advice.
Best wishes,
Grant
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
