On Tuesday 03 December 2002 11:53, Martin Holz wrote:
> the cache of StandardStore is not always cleared, if the
> transaction was rolled back.
>
> I do not understand completely, what is happening, but
> its looks like this.
>
> Clearing will work, if the callback is caused by a
> exception in a child store. In this case, the child store
> will be delisted from the transaction with success ==
> false, which causes the StandardStore to clear the cache.
>
> However, if the rollback is initiated by an external
> source, for example by an exception, which is thrown by a
> ContentInterceptor and catched in AbstractWebdavServlet,
> the StandardStore will never be informed of this, because
> it is not enlisted in the transaction itself.
I wrote a patch to StandardStore, which enlists it the
current transaction whenever a child store is enlisted.
So it gets informed on rollbacks and can clear the
cache. Dirty reads are still possible, but at least
nodes, which where created in aborted transactions
don't hang around in cache forever.
I seems to work, but I am not very comfortable with the
transactional stuff.
Martin
======= StandardStore.java additional methods ============
public void rollback(Xid xid)
throws XAException {
resetCaches();
super.rollback(xid);
}
//
------------------------------------------------------
Protected Methods
protected void enlist(Service service) throws
ServiceAccessException {
if (this != service) {
super.enlist(this);
}
super.enlist(service);
}
/**
* Delist (suspend) the resource manager in the current
* transaction.
*/
protected void delist(Service service, boolean success)
throws ServiceAccessException {
if (!success) {
// If there's a failure which will cause the
transaction to be
// rollbacked, flush the caches
resetCaches();
}
if (this != service) {
super.delist(this,success);
}
super.delist(service, success);
}
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
