I have quite hard problem with JDO efficiency in TJDO implementation. So I am looking for an alternative JDO implementation which can help me avoid that.
Consider such a pseudocode:
tx.begin(); Extent ext=pm.getExtent(AAA.class,...); Query q=pm.newQuery(...); q.declareParameters(...); Collection c=q.executeWithMap(...); q.closeAll(); tx.rollback(); tx.begin(); ext=pm.getExtent(AAA.class,...); q=pm.newQuery(...); q.declareParameters(...); c=q.executeWithMap([the same parms as above]); q.closeAll();
Pay attention to the fact that I am querying twice for exactly the same set of data.
I use similar code to fill JTable data model.
Now, when JDO implementation (RDBMS bridge) get the first query it invokes only one SQL and evaluates result. When it gets to rollback() and begin() it can make two ways: 1. restorevalues==true - rereads all instances on rollback -> many SQLs 2. restorevalues==false - rereads all hollows on second query -> many SQLs
About point 2: it seems that JDO implementation has some references to old hollow objects from the first query. Then it decides not to delete them and read again (which would be fast) but it walks on every single one of them and moves from hollow state reading all its data by one SQL. That way I have one separate SQL for every single object.
Now, should I expect that JDO implementation can be so smart that it can see that using one SQL on second query and replacing hollows is more efficient, than walking on every single present hollow? As I know there are JDO implementations that can use level 2 cache so it can read object from cache not reading from db in above case.
How would JBossDO behave in such code, can it behave efficient? Can I solve this problem using this implementation?
Second question is: can be JBossDO used with standalone app (without JBoss)? My app doesn't need application server (for now :-).
