directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: Caching in Fortress Core
Date Mon, 19 Nov 2018 14:10:41 GMT
On Mon, Nov 19, 2018 at 1:38 PM Shawn McKinney <smckinney@apache.org> wrote:

>
> > On Nov 16, 2018, at 4:20 PM, Emmanuel Lecharny <elecharny@apache.org>
> 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 <mail@stefan-seelmann.de>
> 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

Mime
View raw message