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.)
I agree with you. If it's written in the docs, there are more chances that the HasBroker interface will be upward compatible, compared to the TransactionImpl class.
You mean:
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?
Identity identity = new Identity(aDummyObject,broker)
?
I think you are right. Looking back at the PersistenceBrokerImpl source code, it looks like getObjectByIdentity() is more efficient than getObjectByQuery().
I tried to avoid the PB API and stick to the ODMG, until I ran into performance problems and struggled to make a better use of the cache, that's why I may not use the PB at best.
One more thought: use of the default cache is great, as long as there is no external process making changes in the database, outside of this instance of OJB, which is the case in my app. But if this is not the case (a web app deployed in a cluster without a distributed cache,...), the default behavior of the ODMG queries looks good to me: the DB is checked to make sure there has not been a modification in the data.
Thanks again, Philippe. I look forward to your reply.
You are welcome, I like such profitable exchanges of views.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
