> On Nov 16, 2018, at 4:20 PM, Emmanuel Lecharny <[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? > > On Nov 16, 2018, at 1:56 PM, Stefan Seelmann <[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. —Shawn
signature.asc
Description: Message signed with OpenPGP
