You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Martin Holz <ho...@fiz-chemie.de> on 2002/12/03 11:53:57 UTC
StandardStore Cache and rollback
Hello,
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 suggest the following solution: Delegate caching from
StandardStore to wrappers around NodeStore et al. Since
those wrappers are enlisted in the transaction itself, they
will be notified, if the transaction is rolled back.
Martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: StandardStore Cache and rollback
Posted by Mark Menzies <Ma...@avenida.co.uk>.
Hi Martin,
Thanks for this! I was also having the same problem where the cache was not
rolled back with the database (MySQL in my case with BDB type tables). I
have implemented your patch and rollback is now working properly. Again I'm
not sure of the impact on other areas within Slide as I am only using the
API, but my full set of JUnit tests that ran before are still working. :-)
Maybe another way around this would be to provide some way of flushing the
cache through the API (apologies if there already is an I've missed it)?
Thanks again and best regards,
Mark.
At 10:21 04/12/2002 +0100, Martin Holz wrote:
>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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
Mark Menzies Mark.Menzies@avenida.co.uk
Avenida Technologies Limited http://www.avenida.co.uk
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: StandardStore Cache and rollback
Posted by Martin Holz <ho...@fiz-chemie.de>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>