JSE, JEE, and ResourceAccessor

Resources accessors are the link between PriDE and JDBC, Java’s foundation API for accessing SQL databases. Its main job is to provide JDBC connections for the database that PriDE is supposed to operate on. The accessor must be instantiated before any persistence operation is performed in the code. So usually accessor instanciation takes place somewhere in the application’s bootstrap. In an enterprise application which properly encapsulates database access in repository components resp. data access objects, the accessor may also be lazy-initialized in these components’ lifecycle methods.

PriDE provides two standard implementations, one for JSE and one for JEE environments, which are both derived from the base class pm.pride.AbstractResourceAccessor.


The class pm.pride.ResourceAccessorJSE is used in all examples throughout this manual. It is based on JDBC’s driver manager interface to establish a connection to a database which requires the following information:

Driver class and user/password are passed to the constructor of the resource accessor. As there are a few more optional configuration parameters available, the parameters are passed as a java.util.Properties object to keep the constructor signature simple. How the application assembles these properties is up to you. In the quick start tutorial you already learned about two possible variants - system properties and property files.

The database URL is not part of the resource accessor but is used to register the particular database and its resource accessor in a database context in PriDE’s database factory. So in fact you may access multiple databases of the same type by one resource accessor as you will see in chapter Multiple Databases. The following code snippet demonstrates a minimal bootstrap for a JSE application with a single SQLite database.

Properties props = new Properties();
    ResourceAccessor.Config.DBTYPE, "sqlite");
    ResourceAccessor.Config.DRIVER, "org.sqlite.JDBC");

ResourceAccessor re = new ResourceAccessorJSE(props);



Databases with default support in PriDE are listed in the Interface ResourceAccessor.DBType, so instead of the string literal “sqlite” you should rather use ResourceAccessor.DBType.SQLITE. There are some database types listet which PriDE is known to work on but which are not continuously tested. The permanently tested ones are visible on PriDE’s continuous integration page at Travis CI.


The class pm.pride.ResourceAccessorJEE is suitable for enterprise environments like JEE application servers. It is based on a JNDI lookup of data sources. The database name is not used to specify a database URL but its JNDI lookup name. Driver class, user name, and password are not required, so the minimal bootstrap looks like that:

Properties props = new Properties();
ResourceAccessor re = new ResourceAccessorJEE(props);

You may consider placing the database type into the JNDI context as well to make the application’s bootstrap code completely independent from that issue. Maybe you want to use an HSQL database in test environments which can be killed and re-initialized within seconds while the productive environment is based on an Oracle database.

Accessor Configuration

Beside the basic things like database name and user name there are some more configurations parameters available for the pre-defined resource accessors classes provided with the PriDE distribution. Most of them are concerned with two other aspects which resource accessors are also responsible for: logging and SQL syntax. Every resource accessor has to implement the interface pm.pride.SQL.Formatter which is used by PriDE to produce well-formed SQL value and operator representations. E.g. the method formatValue() called with a string argument is supposed to put single quotes around the string and escape any single quotes and other SQL key characters within the string. If you need to implement your own special resource accessor for some reason, you should usually derive it from class AbstractResourceAccessor which provides reasonable default functionality for these formating issues.

The configuration parameters available for the default implementations are listed in interface ResourceAccessor.Config. The details of all options are documented by their Javadocs. Here is only an excerpt of options which help to understand general aspects: