BRIDGING JAVA OBJECTS AND RELATIONAL DATABASES
BRIDGING
JAVA OBJECTS AND RELATIONAL DATABASES
A: here are some outstanding OJB features:
It's fully ODMG 3.0 compliant
It will have a full JDO implementation
It's higly scalable (Loadbalanced Multiserver scenario)
It provides multiple APIs:
The full fledged ODMG-API,
The JDO API (planned)
and the PersistenceBroker API. This API provides a O/R persistence kernel which can be used to build higher level APIs (like the ODMG and JDO Implementations)
It's able to handle multible RDBMS simultaneously.
it has a slick MetaLevel Architecture: By changing the MetaData at runtime you can change the O/R mapping behaviour. (E.G. turning on/off usage of Proxies.)
It has a simple CacheMechanisms that is fully garbage collectable by usage of weak references.
It has a simple and clean pattern based design.
It uses a configurable plugin concept. This allows to replace components (e.g. the ObjectCache) by user defined Replacements.
It has a modular architecture (you can quite easily reuse some components in your own applications if you don't want to use the whole thing:
The PersistenceBroker (e.g. to build your own PersistenceManager)
The Query Interface as an abstract query syntax
The OQL Parser
The MetaData Layer
The JDBC Accesslayer
It has a very sharp focus: It's concerned with O/R mapping and nothing else.
Before making OJB an OpenSource project I had a look around at the emerging OpenSource O/R scene and was asking myself if there is really a need for yet another O/R tool.
I came to the conclusion that there was a need for OJB because:
There was no ODMG/JDO compliant opensource tool available
There was no scalable opensource O/R tool available
there was no tool available with the idea of a PersistenceBroker Kernel that could be easiliy extended
The tools available had no dynamic MetaData architectures.
The tools available were not as clearly designed as I hoped, thus extending one of them would have been very difficult.
A: please refer to this document.
A: please refer to this document.
A: Sorting can be configured by ojb.broker.query.Criteria::orderBy(column_name).
There is no paging support in OJB. OJB is concerned with Object/Relational mapping and not with application specific presentation details like presenting a scrollable page of items.
OJB returns query results as Collections or Iterators.
You can easily implement your partial display of result data by using an Iterator as returned by ojb.broker.PersistenceBroker::getIteratorByQuery(...).
A: You can do two things to enhance performance if you have to process queries that produce thousands of result objects:
Use getIteratorByQuery() rather than getCollectionByQuery(). The returned Iterator is lazy and does not materialize Objects in advance.Objects are only materialized if you call the Iterators next() method. Thus you have total control about when and how many Objects get materialized!
You can define Proxy Objects as placeholder for your persistent business objects. Proxys are lighweight objects that contain only primary key information. Thus their materialization is not as expensive as a full object materialization. In your case this would result in a collection containing 1000 lighweight proxies. Materialization of the full objects does only occur if the objects are accessed directly. Thus you can build similar lazy paging as with the Iterator. You will find examples in the packages test.ojb.broker
The Perfomance of 1. will be better than 2. This approach will also work for VERY large resultsets, as there are no references to result objects that would prevent their garbage collectability.
A: ODMG is a standard API for Object Persistence specified by the ODMG consortium. JDO is Sun's API specification for Object Persistence. ODMG may well be regarded as a Precursor to JDO, even some of the original ODMG participants are working on the JDO specification. I assume JDO will have tremendous influence on OODBMS and RDBMS vendors to provide compliant products.
OJB currently contains of two main APIs:
A generic PersistenceBroker which provides a minimalistic but (mostly) sufficient API for handling Object Persistence against relational Databases. The PersistenceBroker also provides a scalable multi-server architecture that allows to used it in heavy-duty app-server scenarios.
An ODMG Implementation build on top of this broker. ODMG (www.odmg.org) is an API specification for Object Persistence. It may be regarded as a forerunner to JDO. In fact JDO incorporates many ideas from ODMG and several people who have been involved in the ODMG spec are now in the JDO team.
When I started OJB, JDO was in a very early alpha stage but ODMG was there in a mature and widely accepted 3.0 version. Thus I choose to start with an ODMG Implementation.
One of my aims for OJB is to provide a JDO implementation too. This JDO implementation will be a very thin layer above the existing OJB stuff of PersistenceBroker and ODMG implementation.
There are several things in my ODMG implementation (e.g. the Lifecycle concept) that have been designed with JDO in mind!
A: The PersistenceBroker (PB) provides a minimal API for transparent persistence:
O/R mapping
Retrieval of objects with a simple query interface from RDBMS
storing (insert, update) of objects to RDBMS
deleting of objects from RDBMS
This is all you need for simple applications as in tutorial1.
The OJB ODMG implementation uses the PB as its persistence kernel. But it provides much more functionality to the application developer. ODMG is a full fledged API for Object Persistence, including:
OQL Query interface
real Object Transactions
A Locking Mechanism for management of concurrent threads (apps) accessing the same objects
predefined persistent capable Collections and Hashtables
Some examples explaining the implications of these functional differences:
Say you use the PB to query an object O that has a collection
attribute col with five elements a,b,c,d,e. Next you delete Objects
d and e from col and store O again with
PersistenceBroker.store(O);
PB will store the remaining objects
a,b,c. But it will not delete d and e ! If you then requery object O
it will again contain a,b,c,d,e !!!
The PB keeps no
transactional state of the persistent Objects, thus it does not know
that d and e have to be deleted. (as a side note: deletion of d and
e could also be an error, as there might be references to them from
other objects !!!)
Using ODMG for the above scenario will
eliminate all trouble: Objects are registered to a transaction so
that on commit of the transaction it knows that d and e do not
longer belong to the collection. the ODMG collection will not delete
the objects d and e but only the REFERENCES from the collection to
those objects!
Say you have two threads (applications) that try to access
and modify the same object O. The PB has no means to check whether
objects are used by concurrent threads. Thus it has no locking
facilities. You can get all kind of trouble by this situation. The
ODMG implementation has a Lockmanager that is capable of
synchronizing concurrent threads. You can even use four transaction
isolation levels:
read-uncommitted, read-committed,
repeatable-read, serializable.
In my eyes the PB is a persistence kernel that can be used to build high-level PersistenceManagers like an ODMG or JDO implementation. It can also be used to write simple applications, but you have to do all management things (locking, tracking objects state, object transactions) on your own.
A: please refer to this document.
A: Proxy classes can be used for "lazy loading" aka "lazy materialization". Using Proxy classes can help you in reducing unneccessary db lookups. Example:
Say you load a ProductGroup object from the db which contains a collection of 15 Article objects.
Without proxies all 15 Article objects are immediately loaded from the db, even if you are not interested in them but just want to lookup the description-attribute of the ProductGroup object.
With a proxy class, the collection is filled with 15 proxy objects, that implement the same interface as the "real objects" but contain only an OID and a void reference.
Once you access such a proxy object it loads its "real subject" by OID and delegates the method call to it.
have a look at the ProxyExamples in test.ojb.broker for the source code of this example.
For Example I have a DB column of type INTEGER but a class atribute of type boolean. How can I provide an automatic mapping with OJB?
A: OJB provides a concept of ConversionStrategies that can be used for such conversion tasks. Have a look at the respective document.
$FOOTER$