On 08.04.17 14:40, robertlazarski . wrote: > We need update events because our code already uses them - we are > replacing our current cache libs (ehcache) with another lib - > preferably JCS. > > More specifically, our local cache is filled with stock prices via a > "HTTP server push" stream and on updates we need to perform some > additional calculations using events and listeners.
Although I strongly believe that this should be handled outside the scope of the cache, I think that update events could be added to JCS quite easily. JCS does not support this at the moment. The best place to add such a feature probably would be CompositeCache.update() and remove(), respectively. Please be sure to take the asynchronous nature of event handling into account. > I looked a lot at the JCS code and didn't find update events, which is > why I looked at the JCS JCache implementation. Apparently JSR-107 > didn't define persistence though. I notice some other projects have a > JSR-107 "CacheStore" for disk persistence but to be clear I definitely > want to use JCS. The JCache implementation actually is just a wrapper around JCS, so all features of JCS, including the disk auxiliary should be available from JCache, too. I'm only maintaining the core of JCS, so I cannot speak from JCache experiences here. > Saying this as humbly as possible as clearly I am not a Cache expert , > I am an Apache Axis2 committer plus I have done several Linux related > contributions and I would be willing to submit patches if I end up > having to "scratch my own itch" . Of course though I would rather use > an API that already exists. Patches are always welcome. However I still suggest to reconsider putting data manipulations into the scope of the cache, independently of the library used. Bye, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org