Jena2 Database Interface - Open Issues

2 November, 2004

Open Issues

Persistent Model Interface

There are three different mechanisms for creating persistent models. Users are encouraged to use the factory methods for creating models (ModelMaker and ModelSpec). However, this is a new mechanism that does not yet support all the required functionality for persistent models. The ModelRDB class has methods for constructing Jena2 persistent models. It also has Jena1-compatible methods for creating persistent models. These ModelRDB methods are deprecated but may still be needed by applications until the ModelMaker mechanism is fully functional.

 

Namespace Prefix vs. URI Compression

Jena2 provides persistence for namespace abbreviations. However, this mechanism is separate from the URI compression scheme. This means that the same URI prefix (namespace) may be stored in two different places or a URI may be encoded in two different ways. It might be convenient if a common mechanism were used so that URI compression might reuse existing namespace abbreviations. It is unclear if there is a significant performance impact.

 

Fastpath Testing

If problems are found or suspected in RDQL query processing over the database, the Fastpath code can be disabled and Jena will revert to a simpler, less-efficient mode of query processing. See Fastpath for details on doing this.

 

Known Bugs

Plain Literals vs. XSD String-typed Literals

The RDF recommendation states that if an XSD string-typed literal and a plain literal (no language tag) have the same value (see Literal.getValue()), then they are considered semantically equivalent, i.e., Literal.sameValueAs() returns true.  Unfortunately, the database layer does not treat them as equivalent. For example, if a statement with an xsd string-typed literal for an object is added to a database model, then in a subsequent attempt to list all statements with that value as a plain literal, the original statement (with the typed literal) will not be included in the result set.

Database Lock

The Jena2 storage subsystem uses a lock (or mutex)  internally to implement a critical section for operations that modify the database structure (create/delete tables). The lock is implemented as a database table, i.e., if the table exists in the database, the lock is held. Normally, this lock should be transparent to applications. But if an application has an exception while in a critical section, the database may remain locked for subsequent applications. In this case, a user must manually unlock the database either by calling DriverRDB.unlockDB() or by deleting the table (Jena_Mutex) from the database.

There are many unknown bugs. Unfortunately, we have not had time to do as much testing as we would have liked. Please do not hesitate to contact us on the jena-dev or jena-devel lists when you suspect a problem.