Syncronizing events and RPC calls
36 views
Skip to first unread message
Maverick
Dec 6, 2010, 3:08:03 AM12/6/10
to GWTEventService
I'm trying to use gwteventservice to build an online collaboration
app: users connect to a server and send commands to it through RPC;
the server keeps a central copy of some data structure, and when it
receives commands, it first updates the data structure and then
dispatches commands as events to other users, which uptate theirs own
copy of the data.
So, when a user connects to the server, it first has to retrieve the
existing data structure from the server and then listen for new events
on that data, and here is the problem:
- if I first (a) retrieve the data with a RPC, and then (b) add an
event listener, it can happen that between (a) and (b) some new event
is generated, making "out-of-sync" the data just retrieved by the new
user;
- viceversa, if I first add the listener and then retrieve the data,
it can happen that some event are dispatched before the data is
available.
I think this problem is pretty common for this type of application,
however I haven't found any solution so far. How would you do handle
it with gwteventservice? In general, how do you ensure that a certain
RPC call happen before a gwteventservice event?
app: users connect to a server and send commands to it through RPC;
the server keeps a central copy of some data structure, and when it
receives commands, it first updates the data structure and then
dispatches commands as events to other users, which uptate theirs own
copy of the data.
So, when a user connects to the server, it first has to retrieve the
existing data structure from the server and then listen for new events
on that data, and here is the problem:
- if I first (a) retrieve the data with a RPC, and then (b) add an
event listener, it can happen that between (a) and (b) some new event
is generated, making "out-of-sync" the data just retrieved by the new
user;
- viceversa, if I first add the listener and then retrieve the data,
it can happen that some event are dispatched before the data is
available.
I think this problem is pretty common for this type of application,
however I haven't found any solution so far. How would you do handle
it with gwteventservice? In general, how do you ensure that a certain
RPC call happen before a gwteventservice event?
Luigi Bifulco
Dec 8, 2010, 7:13:37 AM12/8/10
to gwteven...@googlegroups.com
I don't know if exists a standard solution for this problem like a best practice or a design pattern. But i think that your problem can be solved trough "retroactive consumer" described in the above link as feature of the Apache ActiveMQ product. I use gwteventservice too but i don't think that is designed for retroactive consumers. In fact i solved your same problem creating a bridge between ActiveMQ and GwtEventService. Features like message persistence, message delivery ordering, and the concerned retroactive consumer can be found in a JMS product such as Apache or HornetQ by JBoss.
Hoping this was helpful ... my greetings.
--
You received this message because you are subscribed to the Google Groups "GWTEventService" group.
To post to this group, send email to gwteven...@googlegroups.com.
To unsubscribe from this group, send email to gwteventservi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gwteventservice?hl=en.
sven.s
Dec 10, 2010, 12:25:51 PM12/10/10
to GWTEventService
Hi,
the listener has to be registered at first otherwise events/changes
could be lost and your content will become inconsistent. You could
implement a listener which collects all events in a queue till/while
your data is completely received. After that all events can be
processed sequentially.
A similar problem is solved internal of GWTEventService via the
command pattern in combination with a command scheduler. The command
scheduler collects all calls/commands till the initialization server
call is completed. After that the commands are processed and all
following commands are executed directly.
the listener has to be registered at first otherwise events/changes
could be lost and your content will become inconsistent. You could
implement a listener which collects all events in a queue till/while
your data is completely received. After that all events can be
processed sequentially.
A similar problem is solved internal of GWTEventService via the
command pattern in combination with a command scheduler. The command
scheduler collects all calls/commands till the initialization server
call is completed. After that the commands are processed and all
following commands are executed directly.
Luigi Bifulco
Dec 12, 2010, 4:45:44 AM12/12/10
to gwteven...@googlegroups.com
Yes, Sven suggests a good solution i want to add that whatever the "how-to implement" it's right to say that from a good design of your application event/domain can lead a simple optimization: it's unnecessary to execute events of the same type that are olds in terms of time, just the last received can do all the work. So if you want retroactive consumer (implemented via command pattern or with a bridge with a JMS product) i believe u need all events of the same type to be processed, otherwise u don't need retroactive consumer so u need only the last event and a good design of your application event/domain.
Obviously, stateless event triggers a fetch data, while statefull event contains the data to be processed, it's your choice what to do :) good working.
Maverick
Dec 13, 2010, 4:24:26 AM12/13/10
to GWTEventService
Buffering events at listener level is what I was considering to do as
minimum-impact choice.
Btw, if something similar is already implemented in GWTEventService,
it could be useful to make it part if the API in a future version.
On Dec 12, 10:45 am, Luigi Bifulco <bifulcolu...@gmail.com> wrote:
> Yes, Sven suggests a good solution i want to add that whatever the "how-to
> implement" it's right to say that from a good design of your application
> event/domain can lead a simple optimization: it's unnecessary to execute
> events of the same type that are olds in terms of time, just the last
> received can do all the work. So if you want
> retroactive consumer (implemented via command pattern or with a bridge with
> a JMS product) i believe u need all events of the same type to be
> processed, otherwise u don't need retroactive consumer so u need only the
> last event and a good design of your application event/domain.
>
> Obviously, stateless event triggers a fetch data, while statefull event
> contains the data to be processed, it's your choice what to do :) good
> working.
>
> Luigi
>
> 2010/12/10 sven.s <sven.strohsch...@googlemail.com>
> > gwteventservi...@googlegroups.com<gwteventservice%2Bunsu...@googlegroups.com>
> > .
minimum-impact choice.
Btw, if something similar is already implemented in GWTEventService,
it could be useful to make it part if the API in a future version.
On Dec 12, 10:45 am, Luigi Bifulco <bifulcolu...@gmail.com> wrote:
> Yes, Sven suggests a good solution i want to add that whatever the "how-to
> implement" it's right to say that from a good design of your application
> event/domain can lead a simple optimization: it's unnecessary to execute
> events of the same type that are olds in terms of time, just the last
> received can do all the work. So if you want
> retroactive consumer (implemented via command pattern or with a bridge with
> a JMS product) i believe u need all events of the same type to be
> processed, otherwise u don't need retroactive consumer so u need only the
> last event and a good design of your application event/domain.
>
> Obviously, stateless event triggers a fetch data, while statefull event
> contains the data to be processed, it's your choice what to do :) good
> working.
>
> Luigi
>
> > .
Reply all
Reply to author
Forward
0 new messages