Defines the interfaces of the JCR SPI (Service Provider Interface).
The SPI cuts the JCR stack into two parts:
- Above the SPI an implementation that whishes to expose the JCR API again
needs to implement the transient item space, the session local namespace mapping
and various conversions from the value representation in the SPI to
the resolved values in the JCR API.
- An implementation of the SPI interfaces has to deal with the persistent
view of a JCR repository. This includes almost all aspects of the JSR 170
specification, except the previously stated transient space and the session
local namespace resolution to prefixes.
Observation
Because one of the goals of this SPI is to make it easier to implement a
remoting layer using various existing protocols, the observation mechanism has
been design with this goal in mind. Instead of a listener registration with
a callback for each event bundle, the SPI uses a polling mechanism with a
timeout: {@link org.apache.jackrabbit.spi.RepositoryService#getEvents
RepositoryService.getEvents()}. With every call to this method the repository
is advised to return the events that occurred since the last call. As a
reference to the last retrieved {@link org.apache.jackrabbit.spi.EventBundle}
the {@link org.apache.jackrabbit.spi.SessionInfo} contains a bundle identifier
which is automatically updated on each call to RepositoryService.getEvents()
.
While this design allows for a polling implementation on top of the SPI it is
also well suited for a listener based observation implementation on top of the
SPI. With only little thread synchronization overhead events can be acquired
using a timeout
of {@link java.lang.Long#MAX_VALUE}.
If an SPI implementation does not support observation, the method
RepositoryService.getEvents()
will always throw an
{@link javax.jcr.UnsupportedRepositoryOperationException}.