Craig L Russell schrieb:
Hi Jörg,
Is this issue dead now?
Thanks for asking, no, it's not dead, at least not from my part! I head
been waiting for another answer from Wes.
I still think that methods DataStoreCache.invalidateByIdXX() similar to
the evict methods would be very useful. These would discard any cached
state both from the L2-cache as well as from connected L1-caches. They'd
/not/ /evict /any objects from L1-caches: issuing a PM.getObjectById()
before and after DataStoreCache.invalidateById(id) should yield the same
(==) PC instance (same by object reference). Discarding the state of
P-nontrans PC instances in L1-caches probably is best achieved by
transitioning them to hollow state. Also, for any transaction active at
the time of calling invalidateById(), any affected T-clean or T-dirty
instance should also transition to hollow when the transaciton finishes
(probably needs to be more detailed here).
I also think that the evict() methods on DataStoreCache should be
renamed to evictById(), in order to avoid any confusion with the
parameter semantics of the PM.evict() methods that have identical method
signatures. But that's an entirely different issue.
I looked at the javadoc for these methods and they all refer to oid
not pc.
Thanks,
Craig
On Feb 3, 2006, at 1:59 AM, Joerg von Frantzius wrote:
Hello JDO developers,
in our system we have several VMs that operate on the same database
via JDO. We're performing distributed cache invalidation via our own
notification mechanism, which effectively calls
PMF.getDatastoreCache().evict() and PM.evict(). The problem here is
that either evict() accepts only PC objects, not object ids, so we
have to call PM.getObjectById() beforehand. If no object for that id
was present, we're instantiating a hollow object here only to discard
it afterwards, that's not very effective.
As we really want cache invalidation here, not eviction, this is even
worse. For this purpose, it would be far more convenient to have some
method like invalidateCachesFor(Object id) on
PersistenceManagerFactory. To make our wish complete ;) this method
would transition all non-transactional instances to hollow for that
id, for all the PMs the PMF has given out. All transactional objects
with that id should be transitioned to hollow after their transaction
has completed (either with commit or rollback).
Or is there some other way to achieve the same effect?
Thanks for any comments,
Jörg
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
__________________________________________________________
Dipl.-Inf. Jörg von Frantzius | artnology GmbH
| Milastr. 4
Tel +49 (0)30 4435 099 26 | 10437 Berlin
Fax +49 (0)30 4435 099 99 | http://www.artnology.com
_______________________________|__________________________
