I could not find a complete example of selectively clearing the Castor JDO cache(s) in the archives, so, as part of an effort to investigate the use of Castor JDO in a clustered app server environment, I modified it to support the following method in the Database interface class:
/**
* Expire objects from the cache. Objects expired from the cache will
be
* read from persistent storage, as opposed to being read from [either]
the
* performance [or persistent] cache, during subsequent load operations.
*
* Objects may be expired from the cache individually, using explicit
* type/identity pairs in the argument list, or whole classes of objects
* may be expired by specifying a class type without a corresponding
* entry in the identity array.
*
* Objects contained within a "master" object, for example objects
* maintained in a one-to-many relationship, will automatically be
expired
* from the cache without the need to explicitly identify them. This
also
* applies when expiring "master" objects by type. Only the type of the
* containing object needs to be specified.
*
* @param type An array of class types.
* @param identity An array of object identifiers.
*/
public void expireCache( Class[] type, Object[] identity );
I have included a zip file that contains the modified source files. My
additions/modifications are delineated with the following text:
// ----- Modified by Vince Adamo -----
// ----- End modifications -----
I have tested these changes with a stand-alone unit test that I am currently
integrating into the Castor JDO unit test framework. This test validates
that modifications to objects, including objects contained as part of a 1 to
many relationship, are read from the database (as opposed to the cache)
following an expireCache() call.
Note that this implementation marks objects participating in a current read
or write transaction as "expired". When an object is no longer part of any
transaction and has been marked for expiration, it is "cleared" from the
cache (actually it is just not placed back in the LRU cache structures).
Further, note that a commit performed on objects that were modified during a
write transaction, and are, at the same time, modified outside of JDO, will
still throw an object modified exception. This should be an acceptable, and
expected, behavior. These case's are also tested within the unit test.
I am continuing to perform additional functional and performance tests on
these modifications, but I wanted to post the current version of the code
for folks, if interested, to review, test, and provide comments. I am
particularly concerned that, not being 100% (or even 40-50%) familiar with
the architecture, I may have missed something fairly significant. My unit
test works, but it is very likely that I'm not testing for some case that
causes this implementation to fail.
Thanks,
Vince Adamo
<<castor-0.9.3.9-mods.zip>>
castor-0.9.3.9-mods.zip
Description: Binary data
