| - What is Java Persistent Objects (JPOX) ?
-
Java Persistent Objects (JPOX) is an implementation of SUN's JDO specification for java persistence (currently v1.0).
- Is there an overview of JPOX ?
-
JPOX is an implementation of the JDO standard specification (currently v1.0). It provides for storage using RDBMS systems.
It is planned to be extended to allow storage in OLAP databases, as well as other storage media.
- Which datastores are supported by JPOX ?
-
Currently JPOX supports persistence to RDBMS. Many current RDBMS are supported. Please look at
the RDBMS Support Guide for details.
- Is there a roadmap for the future of JPOX ?
-
JPOX version 1.0.0 implements the JDO 1.0.1 specification. The next version of JPOX (1.1.0) will implement the
JDO 2.0 specification tp to a level. It is likely that JPOX version 2.0.0 will be a full implementation of the
JDO 2.0 specification. Our plans change based on the requirements of our users.
- Can you recommend any good books on JDO ?
-
All of the JDO books are good introductions to the subject. If you prefer something to download to get a taster for JDO,
there is a free book on JDO1 by Robin Roos.
- How can I configure JPOX's behaviour ?
-
Various properties are available for modification to control JPOX's behaviour. Please look at
the PersistenceManagerFactory Guide for details of these.
- Can I use JPOX within a J2EE environment ?
-
Yes. JPOX provides a connector facility (using JCA) that allows JPOX to be utilised within a J2EE server (such as
JBoss or WebLogic). Please refer to the J2EE guide for details.
- Can I have some classes persisted with datastore identity and some with application identity ?
-
Yes. JDO treats each class as individual, and so you can have some datastore identity and some application identity.
In addition, you can have some classes mapping to existing datastore tables, and some to tables that will be created by JPOX.
- I've been using another JDO implementation and would like to use JPOX. What do i do ?
-
The only real changes you need to make are to any Meta-Data files. The MetaData file contains two types. The first type
is generic (standard) JDO MetaData defined by the JDO specification. This is common across all JDO implementations and
this will not need changing. The second type is vendor-specific and by definition will be specific to the JDO
implementation being used. The vendor-specific MetaData is contained within the XML tag extension, specifying
the vendor-name attribute that it applies to. If you want your code to run in several JDO implementations you
can include several extension tags some for JPOX and some for your other JDO implementations. This results in
your application being more portable - though clearly the most portable will be MetaData that contains no vendor
extension tags.
- How can I use JPOX in a multithreaded environment ?
-
You need to set Multithreaded as true. You can do it in two different ways:
1. Set the property javax.jdo.option.Multithreaded=true during the PersistenceManagerFactory creation.
2. After creating the PersistenceManagerFactory, call setMultithreaded(true) before creating any
Persistence Managers. After this all PM operations will be thread safe.
- How do I view JPOX's log ?
-
JPOX uses Log4J for logging messages and you can direct the output via a Log4J configuration file. Please take a look
at the Logging Guide which describes all aspects of how to view messages logged by JPOX.
- Can I access my objects outside of a transaction ?
-
Java Persistent Objects (JPOX) allows this but only by making your objects transient. Also, be careful when you have
persistent objects that contain collections of other persisted objects. You need to make use of not just makeTransient,
but also retrieveAll and makeTransientAll. This is because you need to firstly retrieve the collection objects and make
them transient as well. See the following example
tx.begin();
MyClass my_obj = (MyClass) pm.getObjectById(...);
pm.retrieveAll(my_obj.getElements());
pm.makeTransient(my_obj);
pm.makeTransientAll(my_obj.getElements());
tx.commit();
// You can now use my_obj and its contents
- Which enhancer should I use to enhance my classes ?
-
You can use either the JPOX Enhancer (recommended) or the SUN RI enhancer. They are byte code compatible. The JPOX
Enhancer is recommended sicne it provides much more checking of the classes for validity before enhancing. As a result,
basic errors can be caught before runtime. In addition the JPOX Enhancer fixes several bugs in the reference enhancer.
- Does the enhancement of classes affect code coverage tools like Clover or Emma ?
-
You should instrument your classes first, and then enhance them for JDO. This process works with Clover and Emma.
- How can I store long text strings ?
-
You can specify the vendor extension length to any field, hence if you set this to unlimited you
will be allowed to store long strings. The exact length will vary depending on the RDBMS. The length allows
for all 3 types of strings ... fixed length, variable length, and very long.
- How do I create relationships with JPOX ? and how are they managed in the database ?
-
JPOX supports (to varying degrees) all 3 basic types of relationships (1-to-1,
1-to-N, M-to-N) to varying degrees.
Please refer to the documentation for these relationships for details.
- Is it possible to configure JPOX to have element objects deleted when an owner object is deleted ?
-
JPOX supports "cascade-delete" in JPOX 1.1. This is referred to, in JDO 2, as "dependent field". In JPOX 1.0
there is no support for "cascade-delete". It does provide a very limited "clear-on-delete" feature for
Collection/Map relationships (1-N, M-N) but this only clears the link in the element object to the owner object,
leaving the element object alone. "Cascade-delete" is planned to be added in the future. As an alternative, you
can implement this yourself by adding the method jdoPreDelete something like
public void jdoPreDelete()
{
PersistenceManager myPM = JDOHelper.getPersistenceManager(this);
Object[] elements = inverseSet.toArray();
inverseSet.clear();
myPM.deletePersistentAll(elements);
if (!inverseSet.isEmpty())
{
throw new RuntimeException("Elements still left in inverseSet");
}
}
- I use files with different character sets. Can I use JPOX ?
-
Currently JPOX supports English (en) locales using the ISO8859-1 character set. If you include some characters
from ISO8859-1 with accents, or indeed from other character sets, JPOX will call String.toUpper() etc using the
default locale and hence the characters will be changed. Sometimes this change will be to something that causes
an error. The problem is that there is no reliable way of extracting the Locale for the users files. One workaround
would be to use the "table-name" and "column-name" MetaData tags to set the location in the database where the classes
will be persisted, setting them to English characters.
We hope to improve this in the future, maybe by providing an input property defining the Locale of your classes,
though we would prefer to provide an automatic detection facility.
- Is it possible to persist arrays with JPOX ?
-
JPOX currently supports the persistence of arrays of Java primitives (byte[], char[], boolean[], short[], int[],
long[], float[], double[]). Please refer to the Arrays Guide for details.
- Does JPOX load the Meta-Data at startup ?
-
JPOX loads the MetaData for the classes it encounters when it encounters them (dynamically). If you call pm.getExtent()
on a class then JPOX will load the MetaData for that class (and its superclasses) at that time, unless
the MetaData is already loaded. This can have an effect where you want to do a query for all instances
includign subclasses of a particular class. In that case JPOX doesnt know what the possible subclasses
are and so will only retrieve the subclasses that it knows about. The best way to get around this is to
call getExtent() on each of the subclasses first (the first time you meet it only), and then
do the Query. Please refer to the "Auto-Start Mechanism" for details of another way of alleviating these
issues.
- I want to configure JPOX to use a database pool. How do I do this ?
-
There are many ways do to it: please read about them in the
Connection Pooling Guide
- Can JPOX create the database for me ?
-
JPOX cannot currently create the database required for persisting data. It can only create the tables
within an existing database - see below.
- Can JPOX persist data to multiple schemas ?
-
JPOX cannot currently handle this, other than having the data split into separate areas and starting up
separate PersistenceManager's up, one for one schema, and another for another schema etc. We aim to remedy this in the future.
- Can JPOX create the database tables for me ?
-
JPOX can operate in 4 basic modes, that are described in the Mode Guide. JPOX can
be configured to auto-generate any database schema (tables and constraints) that it requires. This is performed
by setting the property org.jpox.autoCreateSchema to true. Alternatively, if you wanted your
database tables creating up-front of running your application, you could use the SchemaTool
utility.
- How do I perform joins in the database using JPOX ?
-
You do not perform "joins" as such yourself. With JDO you hand off the joining of tables to JPOX. Within your
application you handle objects, which have relationships with other objects. As a result you use the JDO query
mechanism to retrieve objects matching specific criteria - see the Query Guide for details.
- Can I obtain a DB connection from JPOX ?
-
This is not currently a standard part of JDO but is supported by JPOX. It is likely to be standardised in JDO 2.0.
To do this use the following.
Connection conn=(org.jpox.AbstractPersistenceManager)pm.getConnection(for_writing);
That is AbstractPersistenceManager, which implements java.jdo.PersistenceManager, has a getConnection method allowing
access to the connection. This is going to be standardised in JDO 2.0, but the name of the method may change.
- Does JPOX store information in the database that it requires ?
-
JPOX, by default, will create a single table in the datastore for storing meta information regarding which classes
and tables it is managing. This has the name "JPOX_TABLES". This behaviour can be turned off by setting the
property "org.jpox.autoStartMechanism" to "none". This will have the effect of not creating and updating this
table, but will also mean that whenever JPOX is restarted it will start with no knowledge of which tables/classes
it was managing the previous time around. Alternatively you could use a different "auto-start" mechanism.
In addition to the "JPOX_TABLES" table, the only things that JPOX will create, other than the basic tables are the following
- On all tables with "datastore" identity, it will add a primary key with a name like "table-name"_ID. If you
have any fields in your class that will clash with this, you can specify MetaData tags to change this name.
- When you specify relationships, the relationship may require a "join" table to be created to model the relationship.
This is explained in the various relationship guides.
As a result, JPOX is not very intrusive at all in the modelling of your datastore allowing you to migrate from JDO
in the future if you wish.
- I've tried inserting many objects and find that it is slow. What is going on ?
-
You are likely using the MaxPoidGenerator to create the identity for the new objects. This makes a database call to get
the next available id. This is the default because it works on ALL RDBMS. We recommend that you replace this with an
AutoIncrement or Sequence based identity generator depending on your RDBMS. Please see
the Identity Generation Guide for details of these and how to select
them in your Meta-Data. The SequenceTablePoidGenerator is recommended since it will work on all databases.
|
