On Mon, Nov 19, 2018 at 1:38 PM Shawn McKinney <[email protected]> wrote:
> > > 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? > 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]> > 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
