Another related issue is that ehcache is a shaded-jar and some of the classes packaged inside it consistently fail our OWASP dependency scan. For our use cases, I'm not sure it gains us much performance either.
Steve ________________________________ From: Emmanuel Lecharny <[email protected]> Sent: Monday, November 19, 2018 9:10:41 AM To: Apache Directory Developers List Subject: Re: Caching in Fortress Core On Mon, Nov 19, 2018 at 1:38 PM Shawn McKinney <[email protected]<mailto:[email protected]>> wrote: > On Nov 16, 2018, at 4:20 PM, Emmanuel Lecharny > <[email protected]<mailto:[email protected]>> wrote: > > Persistent search is definitely an option, I think. Fortress will receive all > the updates coming from the LDAP server, and update the cache accordingly. > Now, that may not be that simple: > * consistency: not such a big deal, as soon as the cache is blocked when it's > updated. Also remember that there is no strong guarantee that what you get > from a LDAP server is up to date, so... > * transactions: if some update impact the cache while its data is being used > by a fortress client, you may be in trouble (ie, the client may be in > trouble). That is something requiring some deep thought. > > Ideally speaking, Fortress cache could be based on MVCC, so that a fortress > client will *always* fetch a consistent version of the data, and that would > guarantee that an incoming update will not impact the clients. Moerever, it > would allow clients to access the cache without any locking issue. I see the cache and transactions as two separate issues. Both have implications that extend beyond the other. For example transactions have import beyond caching and vice-versa. For the record, I can see transactions in fortress’ future. Also agree with idea of using a persistent search to notify of changes. Yes, there may still be rare cases where updates occurring in the client might not coincide with the latest data in the cache but, these are entities that aren’t updated frequently, so the risk is low. What can go wrong? An update will fail that otherwise should have succeeded. My biggest concern is overhead. If every fortress client has a set of persistent searches (there’d be eight right?) what does this do to performance on either tier? No overhead. It's free. The client just get notified when some update occurs. The APi is asynchronous anyway, worse case: you eat a connection (though a thread) waiting for incoming updates. > > On Nov 16, 2018, at 1:56 PM, Stefan Seelmann > <[email protected]<mailto:[email protected]>> wrote: > > Maybe another option c) is to use a distributed cache.If I see correctly > Fortress already uses ehcache which also provides a distributed cache, > Terracotta Server, but I'm not sure about the license. There are also > projects at the ASF like Ignite and Commons JCS. Otherwise there are > Memcached or Redis. The distributed cache was what I had in mind, from the beginning. However, the idea of having another server in place, just to manage these fairly trivial datasets doesn’t feel like an appropriate use today. One, its doubtful that this solution would be available to the community. Two, its worth outweighs the value. The LDAP server *is* your distributed cache, somehow :-) Cordialement, Emmanuel Lécharny www.iktek.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iktek.com&data=02%7C01%7Cswm16%40psu.edu%7Ce000027402744efa78d408d64e28d66b%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636782334634206937&sdata=oMnptoBfsAqqljEpTXOb%2F4mn4oC9IjkiEEAP8tkhazs%3D&reserved=0>
