WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .

The PDS Module provides an implementation of two resource identifier schemes pds: and fpds: They provide a mechanism for persistent storage of representations.

Zones

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...

<config>
  <zone>....some zone id...</zone>
</config>

If no pdsConfig.xml is resolved the 'default' zone is used.

Implementation Engine

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:

<grammar>
  <active>
    <identifier>active:pds</identifier>
    <argument name="instance" min="1" max="1" />
    <argument name="zone" min="1" max="1" />
    <argument name="pds" min="1" max="1" />
  </active>
</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).

Database Backed Persistence

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...

<space name="Your Application Space"> ...Your Stuff...
  <import>
    <uri>urn:org:netkernel:mod:pds</uri>
  </import>
  <import>
    <uri>urn:org:netkernel:mod:pds:rdbms:local</uri>
  </import>
</space>

You would then have pds:/ implemented against an H2 database store. This implementation is persistent between system restarts.

In-memory persistence

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...

<space name="Your Application Space"> ...Your Stuff...
  <import>
    <uri>urn:org:netkernel:mod:pds</uri>
  </import>
  <import>
    <uri>urn:org:netkernel:mod:pds:memory</uri>
  </import>
</space>

In-memory PDS does not support set operations.