WatchService questions

[Sebastian Sickelmann]

Alan Bateman wrote:
> Sebastian Sickelmann wrote:
> > :
> > So a user of the WatchService-API cannot count in the order of the
> events. 
> The sequence of events needs to keep the user's view of the directory 
> consistent. This implies an ordering for at least the create and delete 
> events (irrespective of implementation). Your mails do raise the 
> question on if modification events need to be ordered. Clearly there are 
> cases where they should be ordered with respect to other event kinds. If 
> a file is modified after it is created then you should expect the 
> modification event after the create event. There are other examples like 
> this. If several files are modified at around the same time then the 
> ordering may or may not be useful but clearly cannot be guaranteed 
> everywhere. Where it is important then the user can examine the file's 
> modification time if that helps. So I think you have a worthy point and 
> we should think about this case further to see if we should change the 
> implementation.
I think so to. When someone gets the following Events that happend at time t
the user has no change to exermine the status (ex. Modification-Time, Size) for 
the Event 2. Because the Event raises at t=20 at he receives this Event-List 
sometime after t=40.

4- MODIDY F2 modCount=5 at t=40
3- MODIFY F1 modCount=4 at t=30
2- MODIDY F2 modCount=3 at t=20
1- MODIDY F1 modCount=2 at t=10

So you gain no more information that in this example:

4- MODIDY F2 modCount=8 at t=40 t=20
3- MODIFY F1 modCount=6 at t=30 t=10

Naturally t=xyz should not be an information of the events. 


>If it is changed then there are several possible 
> approaches - for example modification events could be merged towards the 
> head if the pending list reaches its limit. Alternatively modification 
> events could initially be stored in a map (for fast lookup) and only 
> added to the pending list when an event of a different kind needs to be 
> queued (or the user retrieves the pending events).
This are exactly the 2 Mainimplemetatios i see too. 
1. Merging MODIFY-Events and move to Head
2. Merging MODIFY-Events and leave them in there Position. (Searching can be done via HashMap)

Implementation 1. Merging MODIFY-Events
=======================================
Searching the List in linear Order can lead to fast results, but only if the list is reorderd.
The question is: How much the reorderung in the Event-List hurts.
In single Threaded modifiying of the watched directory there is a slightly good change to find
older MODIFY-Events to the some context very fast at the head of the list. But in Multithreaded
uses of the Directory there will only a few hits at the head of the list.
The order of the MODIFY-EVENTS of different contexts are than relative to the ==last== Modification of the contexts.

Implementation 2. Merging MODIFY-Events and leave them in there Position. (Searching can be done via HashMap)
=============================================================================================================
Searching a MODIFY-EVENT in an HashMap should be pretty fast. Incrementation could be done in the found MODIFY-Event.
If the top-most Event is a MODIFY-EVENT to the same context, lookup at the head of the list would be faster.
At EVENTS like CREATE and DELETE the HashMap should be cleared(Implementation 2A). Alternativ only the MODIFY-EVENTS
of the same context can be removed from the Map (Implementation 2B).
I think both solutions (Implementation 2A and 2B) are only realy good in multithreaded environments. When there is only 
one other programm or thread that writes to the watched Directory Implementation 1 will be faster.
The order of the MODIFY-EVENTS of different contexts are than relative to the ==first== Modification of the contexts.

But what should be done with other Events than StdWatchEventKind?

Are there implementation specific EventKinds? And must there be a way(overrideable protected Method) so that implementations can override Merging and Reordering of Events?

I have made two(2A,2B) Test-Implemetations and it seems to work and reduce MODIFY-Events.

- Sebastian
> 
> -Alan.
> 

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser