Following is a summary of how the current implementation of caching works:

- Existing events are loaded to the cache in lazy manner when they are
looked-up.
- When adding/removing events both cache and table is updated accordingly.
- When reading, cache is searched first and then the DB table. For events
that do not exist in the cache, they get added to the cache at this moment
and evictions happen if necessary.
- The events in the cache are evicted based on 3 algorithms. They are Least
Recently Used, Least Frequently Used and FIFO. User can choose what to use
in their query. (This is configurable per-table basis). Events get evicted
when the cache reaches the upper limit.
- Currently upper limits are constant (this implementation can be changed
easily to have a configurable value if needed - it's possible to allow the
user to define upper limits in the query)
- Currently caches do not support the distributed mode. This is not
implemented since there are pending changes to our distributed processing
implementation.
- Also in a future release we need to change the implementation of how Join
operations are done in Siddhi. With the current implementation, caches
can't be used effectively for Joins.

The documentation can be found at [1]

[1] https://docs.wso2.org/display/CEP310/Event+Table+Definitions


On Fri, Mar 14, 2014 at 7:25 AM, Srinath Perera <[email protected]> wrote:

> How it works? when does it evict things? can we set limits.
>
> Please respond to this with details about the design
>
> --
> ============================
> Srinath Perera, Ph.D.
>    http://people.apache.org/~hemapani/
>    http://srinathsview.blogspot.com/
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Rajeev Sampath
Senior Software Engineer
WSO2, Inc.; http://www.wso2.com.

Mobile:
* +94716265766*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to