Re: How to program against the ODMG personality correctly?

[Philippe Hacquin]

Hi Sean,

I'm not an OJB-ODMG expert, but maybe I can help

Sean Dockery wrote:
[...]
1) The exception handling code is omitted from the examples for the sake
 of brevity.  Is the manner in which I'm handling exceptions correct?
Take care of the following:

        Transaction tx = implementation.newTransaction();
        tx.begin();
        try
        {
            ....
            tx.commit();
        }
        catch (Throwable t)
        {
            tx.abort();
            throw new DaoException(t);
        }
You may catch a TransactionAbortedException, which in this case will 
leave tx null, thus you will end with a NPE if you execute tx.abort()


2) I've written my retrieval routine to use a persistence broker query.
Using persistence broker queries in this manner is apparently faster.  In
a reply in another thread, I read...
"Philippe Hacquin" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
... and they are much more efficient, too, because they use the cache.
This confuses me somewhat.  Does this mean that the ODMG personality of
OJB doesn't use caching?  Or do OQL queries bypass caching?
I've recently made some performance tests, with p6spy and network traces 
to monitor the queries sent to the database. I am using ODMG in OJB 1.0 
RC4, too.
Say you have a class A that has some properties, with at least the "id" 
property which is mapped to the primary key of your table (hence, you 
don't use anonymous keys).
You want to get a reference to a persistent object using the id. So you 
write an OQL query like "select anInstance from " + A.class.getname() + 
"where id = \"" + id + "\""
Well, you have to know this ODMG query will lead to a straight SQL query 
to the database, even if the object is already in the cache. But the 
cache will anyway be looked up after the SQL query, to check if the 
materialization process can be avoided. This process consumes some time, 
you can check that during some tests. So an ODMG query uses the cache, 
but does not use at 100%.
To use the cache in an effectively manner, you have to use a PB query 
against the object Identity (well, this is what I deducted, if there is 
a more efficient way to do it with the default cache, I'd like to hear 
about it).
This is the way I code it:

   PersistenceBroker broker = ((TransactionImpl) tx).getBroker();
   A aDummyObject = new A();
   aDummyObject.setId(id);
   Query qry = new QueryByIdentity(aDummyObject);
   A result = (A) broker.getObjectByQuery(qry);
This way the cache is looked up _before_ querying the DB.
This was not obvious when I began using OJB, but should have if I had 
carefully read the "Object cache" documentation: the lookup() method 
takes an Identity instance as search key in the cache.
Well, I supposed this was handled transparently in the ODMG 
implementation layer...

HTH

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]