Oh, I didn't realize that ROP clients have their own independent views of
the data and that commits are not visible to others. (They seem to refresh
sometimes when I run a fresh query, but other times, they are not.
Collections don't refresh at all...) I thought there were a number of
projects using ROP in production environment and I would imagine this is a
common requirement. How are people getting around it if at all?Building
event propagation on the server would be great, but as you say, it's non
trivial. So in the meantime, I would need to find another solution (other
than rewriting my entire swing gui in gwt...) How would I refresh all
caches programmatically? I ll try that and see what performance looks
like...
Tarik
On Fri, Feb 13, 2009 at 12:28 AM, Aristedes Maniatis <ar..sh.com.au> wrote:
>
> On 13/02/2009, at 3:30 PM, Tarik Cherkovi wrote:
>
> Hi,I just had a strange behavior from ROP and maybe missing something
>> basic.
>> I have multiple clients connecting to the same server, and when one of
>> them
>> performs a commit, the changes are not visible to the other client(s). Is
>> there a way to make all remote contexts?
>>
>
> You'll need to implement that behaviour yourself. Obviously the simplistic
> approach is to refresh all caches and queries on the remote client before
> you use data where freshness is important.
>
> The problem isn't a trivial one. If you have a bunch of clients on
> different subnets, they can't necessarily pass events directly to each other
> using JMS or something similar. So the server needs to be responsible for
> holding a list of update events which are then passed out to clients upon
> request. You could implement something with SnapshotEvents [1] which are
> passed either directly between clients (if they have direct access to each
> other) or via the server as an intermediary. Personally I didn't get much
> further than identifying a couple of libraries such as Apache Mina and
> Apache ActiveMQ which might be useful in such an implementation.
>
> But I am keen on implementing something for our own applications, if only
> we had more time....
>
> Ari
>
>
> [1] http://cayenne.apache.org/doc/object-caching.html
>
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
This archive was generated by hypermail 2.0.0 : Fri Feb 13 2009 - 00:44:28 EST