Framework/Another Lore2009. 4. 24. 08:42



A repository may support observation, which enables an application to receive notification of persistent changes to a workspace.

Event Model
A persisted change to a workspace is represented by a set of one or more events. Each event reports a single simple change to the structure of the persistent workspace in terms of an item added, changed or removed. The six
standard event types are:

NODE_CREATED, NODE_REMOVED
PROPERTY_CREATED, PROPERTY_CHANGED
LINK_CREATED, LINK_REMOVED


Scope of Event Reporting


The scope of event reporting is implementation-dependent. An implementation should make a best-effort attempt to report all events, but may exclude events if reporting them would be impractical given implementation or resource limitations. For example, on an import, create or remove of a subgraph containing a large number of items, an implementation may choose to report only events associated with the root node of the affected graph and not those for every subitem in the structure.

Event implement
NodeEvent, PropertyEvent, LinkEvent


Event Information
Each Event is associated with a path, an identifier and an information map, the interpretation of which depend upon the event type.

The event path is retrieved through
  NodeEvent.getNode()
  PropertyEvent.getProperty() ;
  LinkEvent.getLink() ;

User ID
An Event also records the identity of the Session that caused it. String Event.getUserID()
String Event.getUserID()
returns the user ID of the Session, which is the same value that is returned by Session.getUserID()


Event Date

An event also records the time of the change that caused it. This acquired through
long Event.getDate()
The date is represented as a millisecond value that is an offset from the epoch January 1, 1970 00:00:00.000 GMT (Gregorian). The granularity of the returned value is implementation-dependent.


Event Ordering

In both asynchronous and journaled observation the order of events within a bundle and the order of event bundles is not guaranteed to correspond to the order of the operations that produced them.

Observation Manager

Registration of event listeners is done through the ObservationManager object acquired from the Workspace through
ObservationManager Workspace.getObservationManager().


Exceptions

The method EventListener.onEvent does not specify a throws clause. This does not prevent a listener from throwing a RuntimeException, although any listener that does should be considered to be in error.


[Example Code]
  EventStackingListener listener = new EventStackingListener();
  workspace.getObservationManager().addEventListener(listener) ;
  
  Node node = session.createNode(root, newType, "abc") ;
  
  assertEquals(3, listener.getCount())  ;
  
  NodeEvent event = (NodeEvent)listener.popEvent();
  assertEquals(EventType.NODE_CREATED, event.getType()) ;
  assertEquals(node, event.getNode()) ;
  assertEquals(EventType.LINK_CREATED, listener.popEvent().getType()) ;
  assertEquals(EventType.PROPERTY_CREATED, listener.popEvent().getType()) ; // because of default value
  
  node.setProperty(IDString.propId("firstname"), "bleujin") ;
  assertEquals(EventType.PROPERTY_CHANGED, listener.popEvent().getEventType()) ;


<interface Event>
 public EventType getType() 
 public String getUserID() 
 public long getDate()


<interface EventListener>
 public void onEvent(Event event);
 public boolean isDealWith(Event event);

'Framework > Another Lore' 카테고리의 다른 글

AL : Reading  (0) 2009.04.25
AL : Link  (0) 2009.04.24
AL : Observation  (0) 2009.04.24
AL : Versioning Model  (0) 2009.04.24
AL : Workspace  (0) 2009.04.23
AL : Node  (0) 2009.04.23
Posted by bleujin

댓글을 달아 주세요