The PDS Module provides an implementation of two resource identifier schemes pds: and fpds: They provide a mechanism for persistent storage of representations.
PDS persists representations into zones, this allows pds:/ space to be disambiguated for different applications within the same host. Providing a globally unique zone identifier for your application therefore allows it to maintain a separate persistence address spaces without fear of overlap with other applications.
To determine which zone is being used the pds:/ accessor SOURCEs the resource:
res:/etc/pdsConfig.xml
which in XML looks like...
If no pdsConfig.xml is resolved the 'default' zone is used.
Internally the pds:/ accessor is a thin front-end - it determines the NetKernel instance name, the zone and the pds:/ identifier - it then makes a sub-request to an active:pds implementation engine which must provide the physical-level persistence mechanism.
An engine must have the following interface grammar:
The implementation service must support the 4 verbs and must store data unambiguously based upon the 3 argument identifiers.
Persistence engines are pluggable and are simple to create if you wish to leverage your own storage infrastructure. There are two implementations provided in the pds module in independent rootspaces.
To use an implementation you must import it as companion to the primary urn:org:netkernel:mod:pds front-end (see examples below).
An H2 database-backed persistence engine is provided from the secondary space :
urn:org:netkernel:mod:pds:rdbms:local
To use this implementation you would import both of these spaces...
You would then have pds:/ implemented against an H2 database store. This implementation is persistent between system restarts.
An in-memory implementation backed by a HashMap is provided by the space :
urn:org:netkernel:mod:pds:memory
To use this implementation you would import both of these spaces...
In-memory PDS does not support set operations.
Persistent data service
pds: