Hello, Philippe. Thanks for the analysis and tip about the performance of ODMG in relation to caching objects. That is helpful.
I have a question for you about your little snippet... > PersistenceBroker broker = ((TransactionImpl) tx).getBroker(); > A aDummyObject = new A(); > aDummyObject.setId(id); > Query qry = new QueryByIdentity(aDummyObject); > A result = (A) broker.getObjectByQuery(qry); On the OJB web site, it shows the following usage. PersistenceBroker broker = ((HasBroker) tx).getBroker(); The use of "HasBroker" seems cleaner than "TransactionImpl" to me. I know that since 0.9.8 that classes have disappeared. :-( (I'm working on an application that uses a closed-source third party library based on OJB 0.9.8; I know that classes have disappeared because I couldn't run the application with OJB 1.0.) You could also do this instead... Identity identity = new Identity(aDummyObject); A result = (A) broker.getObjectByIdentity(identity); Is there any difference in behaviour betwen "getObjectByQuery" and "getObjectByIdentity" when it comes to caching? Or is it just a style (using query vs. identity) preference? Thanks again, Philippe. I look forward to your reply. "Philippe Hacquin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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]
