Return-Path:
+ Q: I just tried to turn caching off by using ObjectCacheEmptyImpl setting
+ in ObjectCacheClass, and it seems to continuously loop through the SQL
+ statement infinitely. The default works fine though.
+
+ Any ideas why this might be?
+
+ A: The Problem you see is due to circular references in your data.
+ Say A references B and B has a backreference to A.
+
+ Now we load A from the DB. If autoretrieve="true" for the reference-descriptor
+ defining the reference to B, OJB will also load B.
+ If autoretrieve="true" for the B-reference-descriptor describing
+ the back-reference to A, OJB must retrieve A. And here is the key point.
+
+ If we use the defaultcache A will be in the cache already, as it was loaded first.
+ So OJB will simply lookup A from the cache. No endless recursion!
+
+ But if we use the emptycache, A will not be cached. So OJB must load A from the DB.
+ And then again B is retrieved, etc., etc.
+ There's you endless recursion.
+
+ In other words: A non-empty cache is needed to allow proper loading of circular
+ references. (Other O/R tools like TopLink work the same way).
+
+ If you still want to use the EmptyCacheImpl you should set autoretrieve="false"
+ and load references explicitely by broker.retrieveReference(...).
+
javax.jdo.spi.PersistenceCapable
.
+ If a class does not implement this interface a JDO implementation does not know how to
+ handle it.
+ javax.jdo.spi.PersistenceCapable
to the the user classes.
+ This "injection" could be achieved by Pre- or Post-processing.
+ The strategy most implementations use is called "bytecode-enhancement".
+ This is a postprocesing step that adds the required methods to the .class files
+ of the persistent user classes.
+ javax.jdo.spi.PersistenceCapable
interface use the ant target
+ "enhance-jdori" before launching the tutorial5 application.
+ This is documentated in the first section of tutorial4.html.