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 Daniel Florey <df...@apache.org> on 2004/07/26 14:49:05 UTC

Re: How to make Slide faster

It would be great to improve the performance of Slide.
My favorite approach regarding the lock and security checking would be 
to use the event framework.
There could be something like a SecurityListener implementing all the 
relevant interfaces (ContentListener, StructureListener...) and 
performing the security checking. This would help to slim down the Slide 
core methods and would make the security and lockin stuff pluggable.
The listener can do the permission checking as well as invalidating the 
acl-cache.
I'd help to migrate the current code  to an event based approach if 
appreciated.
Regards,
Daniel

Oliver Zeigermann schrieb:

> I am currently thinking about how Slide could be made faster with 
> little effort. As the main source of Slide being slow I identified method
>
> public ObjectNode retrieve(SlideToken token, String strUri,
>                                boolean translateLastUriElement)
>
> in StructureImpl and lock and securiy checks.
>
>
> As I don't want to change much, maybe some sort of *direct* caching 
> could do that maps the string Uri to the Object Node resp. to locking 
> and security data. It would, however, be complicated to determine 
> which calls to Slide invalidate the entries.
>
> Any ideas? Comments?
>
> 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: How to make Slide faster

Posted by Oliver Zeigermann <ol...@zeigermann.de>.
This would fit my plans, as direct (high-level) caching would require 
transactional control, isolation and a reliable invalidation mechanism. 
With the current design I see no clean, straight forward approach to add 
this to the Slide kernel.

However, as this would involve severe changes to the Slide kernel, this 
is nothing that can go into a 2.1 release. I would thus recommend to 
defer this until 2.1 feature freeze, create the 2.1 release branch and 
do the changes in the Slide head afterwards.

Oliver

Daniel Florey wrote:
> It would be great to improve the performance of Slide.
> My favorite approach regarding the lock and security checking would be 
> to use the event framework.
> There could be something like a SecurityListener implementing all the 
> relevant interfaces (ContentListener, StructureListener...) and 
> performing the security checking. This would help to slim down the Slide 
> core methods and would make the security and lockin stuff pluggable.
> The listener can do the permission checking as well as invalidating the 
> acl-cache.
> I'd help to migrate the current code  to an event based approach if 
> appreciated.
> Regards,
> Daniel
> 
> Oliver Zeigermann schrieb:
> 
>> I am currently thinking about how Slide could be made faster with 
>> little effort. As the main source of Slide being slow I identified method
>>
>> public ObjectNode retrieve(SlideToken token, String strUri,
>>                                boolean translateLastUriElement)
>>
>> in StructureImpl and lock and securiy checks.
>>
>>
>> As I don't want to change much, maybe some sort of *direct* caching 
>> could do that maps the string Uri to the Object Node resp. to locking 
>> and security data. It would, however, be complicated to determine 
>> which calls to Slide invalidate the entries.
>>
>> Any ideas? Comments?
>>
>> 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
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org