I've made the change but actually, the problem is a little bit more convoluted. The basic idea was that SimpleCache used for repository in cluster mode would cause problems (data inconsistency in the repository). After looking at the usages I've noticed that there are some parts of the code that may still may benefit from using SimpleCache (DNSResolver*) or they simply reference it without actually doing much with it (@tigase.component.adhoc.AdHocCommandManager#process()@ -- %bmalkow - could you expound on the use of SimpleCache and AdHocSession there?).

As for repositories -- except for JDBC repository Cache is not used.

The time parameter seems to also be ignored...

We could:

• remove SimpleCache from JDBCRepository and remove the constrains that would disable it in cluster mode;

• remove SimpleCache altogether;

• improve SimpleCache (time based items removal, remove disabling when clustering with documenting that it may yield wrong results while using with repositories).

Wojciech Kapcia wrote:

• improve SimpleCache (time based items removal, remove disabling when clustering with documenting that it may yield wrong results while using with repositories).

I am in favor of going this route. I think we should seek performance improvements and optimizations. Using some sort of cache, even in clustered env is very much desired. Maybe not on the DB level but maybe on application level (PubSub, MUC, etc....). That is on the components level which are aware of clustered env and can automatically invalidate cache in case of some changes in other cluster nodes.

My assumption is that for the most part we do reading from DB and then the cache might be very useful. When we do writing in DB we could send a message through the cluster to empty cache. This is not super optimal but could still provide improvements.

For sure, this needs more research and work to make it usable in clustered env.

Artur Hefczyc wrote:

Wojciech Kapcia wrote:

• improve SimpleCache (time based items removal, remove disabling when clustering with documenting that it may yield wrong results while using with repositories).

I am in favor of going this route. I think we should seek performance improvements and optimizations. Using some sort of cache, even in clustered env is very much desired. Maybe not on the DB level but maybe on application level (PubSub, MUC, etc....). That is on the components level which are aware of clustered env and can automatically invalidate cache in case of some changes in other cluster nodes.

My assumption is that for the most part we do reading from DB and then the cache might be very useful. When we do writing in DB we could send a message through the cluster to empty cache. This is not super optimal but could still provide improvements.

For sure, this needs more research and work to make it usable in clustered env.

AFAIR PubSub (and possibly MUC) are already using caching (and there is cache hit-miss ration in statistics) but this is probably done by just using a collection (map?) -- %andrzej.wojcik ?

%wojtek MUC and PubSub are using custom caches adjusted to them. They are based on a Map and List to make sure that access is concurrent and fast and we will invalidate older entries. Moreover, clustering strategies are taking care of notifying other nodes about items to invalidate in case, and in some cases provide other nodes with new values to use as in some cases it was far better (faster) than rereading data from the database.