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 Andreas Probst <an...@gmx.net> on 2004/07/07 21:01:00 UTC
StandardStore, AbstractStore, caching
Hi all,
for the project I'm working in I need to change the caching
behaviour of Slide. Looking at StandardStore, which does the
caching, I wonder:
If caching is disabled, read calls are forwarded to super
(AbstractStore), which then calls the actual Store
implementation.
If caching is enabled but the object to read is not in the
cache, the calls are not forwarded to super but to the actual
Store implementation, e.g. DescriptorsStore.
Why is it done this way? Is it just style?
When super is called, the Stores are listed in a transaction...
I think this is important to understand when I change the way
the caching is done.
Please see one example below.
Thanks.
Andreas
StandardStore:
public ObjectNode retrieveObject(Uri uri)
throws ServiceAccessException, ObjectNotFoundException {
if (nodeStore.cacheResults()) {
Object tempObject =
objectsCache.get(uri.toString());
if (tempObject != null) {
return ((ObjectNode) tempObject).cloneObject();
} else {
ObjectNode objectNode =
nodeStore.retrieveObject(uri);
objectNode.validate(uri.toString());
objectsCache.put(uri.toString(),
objectNode.cloneObject());
return objectNode;
}
} else {
return super.retrieveObject(uri);
}
}
AbstractStore:
public ObjectNode retrieveObject(Uri uri)
throws ServiceAccessException, ObjectNotFoundException {
ObjectNode objectNode = null;
if (isForceStoreEnlistment(uri)) {
enlist(nodeStore);
try {
objectNode = nodeStore.retrieveObject(uri);
} catch (ServiceAccessException e) {
delist(nodeStore, false);
throw e;
} catch (ObjectNotFoundException e) {
// Note : Failed reads aren't considered fatal
(ie, the
// transaction won't be always rolledback when
committed)
delist(nodeStore);
throw e;
} catch (Throwable t) {
delist(nodeStore, false);
// Wrap everything else in a
ServiceAccessException
throw new ServiceAccessException(nodeStore, t);
}
delist(nodeStore);
} else {
try {
objectNode = nodeStore.retrieveObject(uri);
} catch (ServiceAccessException e) {
throw e;
} catch (ObjectNotFoundException e) {
throw e;
} catch (Throwable t) {
// Wrap everything else in a
ServiceAccessException
throw new ServiceAccessException(nodeStore, t);
}
}
objectNode.validate(uri.toString());
return objectNode;
}
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: StandardStore, AbstractStore, caching
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
Hi Andreas!
Sorry, I thought you were referring to the ExtendedStore. Do *not* use
StandardStore as it has been marked deprecated. Please, use ExtendedStore.
Thanks,
Oliver
Andreas Probst wrote:
> Hi Oliver,
>
> thank you for the quick response. Sorry, but I copied it from
> cvs head. It's not fixed there. Below are the ID tags.
>
> /home/cvspublic/jakarta-slide/src/share/org/apache/slide/store/AbstractStore.java,v 1.42 2004/06/23 09:13:42 ozeigermann Exp $
> /home/cvspublic/jakarta-slide/src/share/org/apache/slide/store/StandardStore.java,v 1.22 2004/02/11 11:30:18 ozeigermann Exp $
>
> Regards,
>
> Andreas
>
> On 7 Jul 2004 at 23:54, Oliver Zeigermann wrote:
>
>
>>Andreas Probst wrote:
>>
>>>for the project I'm working in I need to change the caching
>>>behaviour of Slide. Looking at StandardStore, which does the
>>>caching, I wonder:
>>>
>>>If caching is disabled, read calls are forwarded to super
>>>(AbstractStore), which then calls the actual Store
>>>implementation.
>>>
>>>If caching is enabled but the object to read is not in the
>>>cache, the calls are not forwarded to super but to the actual
>>>Store implementation, e.g. DescriptorsStore.
>>>
>>>Why is it done this way? Is it just style?
>>>When super is called, the Stores are listed in a transaction...
>>
>>I guess you are referring to 2.0, right? I have done this stuff and as
>>far as I remember, it was just non sense and I fixed it in the current
>>CVS head.
>>
>>Oliver
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: StandardStore, AbstractStore, caching
Posted by Andreas Probst <an...@gmx.net>.
Hi Oliver,
thank you for the quick response. Sorry, but I copied it from
cvs head. It's not fixed there. Below are the ID tags.
/home/cvspublic/jakarta-slide/src/share/org/apache/slide/store/AbstractStore.java,v 1.42 2004/06/23 09:13:42 ozeigermann Exp $
/home/cvspublic/jakarta-slide/src/share/org/apache/slide/store/StandardStore.java,v 1.22 2004/02/11 11:30:18 ozeigermann Exp $
Regards,
Andreas
On 7 Jul 2004 at 23:54, Oliver Zeigermann wrote:
> Andreas Probst wrote:
> > for the project I'm working in I need to change the caching
> > behaviour of Slide. Looking at StandardStore, which does the
> > caching, I wonder:
> >
> > If caching is disabled, read calls are forwarded to super
> > (AbstractStore), which then calls the actual Store
> > implementation.
> >
> > If caching is enabled but the object to read is not in the
> > cache, the calls are not forwarded to super but to the actual
> > Store implementation, e.g. DescriptorsStore.
> >
> > Why is it done this way? Is it just style?
> > When super is called, the Stores are listed in a transaction...
>
> I guess you are referring to 2.0, right? I have done this stuff and as
> far as I remember, it was just non sense and I fixed it in the current
> CVS head.
>
> Oliver
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: StandardStore, AbstractStore, caching
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
Andreas Probst wrote:
> for the project I'm working in I need to change the caching
> behaviour of Slide. Looking at StandardStore, which does the
> caching, I wonder:
>
> If caching is disabled, read calls are forwarded to super
> (AbstractStore), which then calls the actual Store
> implementation.
>
> If caching is enabled but the object to read is not in the
> cache, the calls are not forwarded to super but to the actual
> Store implementation, e.g. DescriptorsStore.
>
> Why is it done this way? Is it just style?
> When super is called, the Stores are listed in a transaction...
I guess you are referring to 2.0, right? I have done this stuff and as
far as I remember, it was just non sense and I fixed it in the current
CVS head.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org