On 1.12.11 13:21, Jukka Zitting wrote:
IIUC you want to "auto-refresh" all sessions each time observation events
are being delivered?
Only those sessions to which events are being delivered, i.e. ones
that have explicitly registered an observation listener.
Hmm I remain skeptical ;-)
Why do we 'obviously' need this? I understand, there will be a change from
the current behaviour: while today sessions can't see items anymore which
they get DELETE events for, in the new implementation sessions can't see
items yet which they get ADD events for. From that perspective the new
behaviour seems more flexible and complete: sessions can see deleted
items until they do a refresh. Afterwards they can see the added items.
One of the few hard guarantees that we make to an observation listener
is that when an event is received, that change has already happened.
If the session state isn't refreshed when an even is delivered, then
the session would essentially be seeing into the future. I guess that
might be useful for some things like you mention, but to me that
sounds counterintuitive and as mentioned by Felix will likely trip off
many existing clients.
Yes I share this concerns. As I mentioned in earlier reply another
approach we discussed some time ago is to have read only sessions which
are always on the newest revision (i.e. see all saved changes).
Observation listeners on such sessions would then behave as they did
with JR2. Since the underlying Microkernel implements an MVCC approach
such read only sessions would be very easy and cheap to implement.
Michael
