PriDE FAQ
What is PriDE?
PriDE stands for 'Primitive Database
Environment' and is a simple O/R mapper for relational
databases. O/R mapping is the wide-spread approach to map records of a relational
SQL database to objects of a object-oriented application. See PriDE Introduction.
What does PriDE?
The PriDE Featurelist should help
to figure out wether PriDE is suitable for particular requirements. It also
allows a rough comparison with other well-known O/R mapping toolkits.
In which environments can PriDE be used?
PriDE is suitable for both J2SE and J2EE environment. Its ResourceAccessor
interface also allows to integrate PriDE in any other resource management
infrastructure. Since release 2.0.3 e.g. there is a ResourceAccessorWeb
delivered for easy integration in servlet engines like Tomcat.
Is PriDE fast enough?
Yes, it defnitely is! PriDE does not provide things like transparent caching
or a load/store optimization and therefore does not claim to be faster
than the underlaying database. But on the other hand it always works
straight-forward and does not show unexplainable side-effects when being
used in complex applications. For standard operations its performance is
very close to plain JDBC, i.e. clearly faster than most other O/R mapping
toolkits.
Can I work with multiple databases in PriDE?
Mutiple databases can be accessed by PriDE's concept of database contexts
(see the PriDE Introduction).
You just have to keep in mind that PriDE doesn't perform a sophisticated
transaction and resource management. E.g. if you need distributed 2-phase-commit
for resource-spanning transactions, you are supposed to run PriDE on an application
server.
Tomcat sometimes dies when using PriDE in servlets!
This is probably caused by PriDE's old default severe error handler which just
prints an exception stack trace and calls System.exit(1). This behaviour has been
changed since version 2.3.1 to throw a RuntimeException instead. You can also check
the servlet example from the PriDE destribution how to handle severe error situations
in a less restrictive way. However, you should spend some time thinking over if your
application is actually able to continue working properly after unexpected severe
error situations. It is often difficult to garuantee a consistent state of the
application's internal data.
Do I have to organize transactions?
PriDE does not perform any transaction management, so it depends on the runtime
environment what to do. When running PriDE in a J2EE environment you can
rely on the application server's transaction and resource management and
use CMP for instance if you don't want your code to manage transactions.
In J2SE environments, transactions must definitely by managed by the application.
However, the ResourceAccessorJ2SE at least propagates open connections
by a ThreadLocal allowing to share a connection by all functions
along a call chain and terminate transactions only on the top level. So it
is usually very simple to organize.