Skip to content

Conversation

@vincentvanbush
Copy link
Contributor

If a translation is available in the local hash, it's loaded from the hash; if it's not, it's loaded into the hash from Redis. Therefore arises the necessity to update the hash when it's needed.

Every time a translation is changed in any way, current timestamp is stored into Redis. In the application, a timestamp snapshot is stored and every request it is compared to the timestamp stored in Redis. If the local snapshot is older than the data in Redis, the local snapshot is updated - hash is cleared.

@mlitwiniuk
Copy link
Member

@vincentvanbush could you add tests to it (one ie. prooving, that local cache is used even if ie. redis got cleared, second prooving, that updating translation clears cache?) I wonder how we can test this in multi-threaded env

Another thing - there are some conflicts now and this can not be merged.

@vincentvanbush
Copy link
Contributor Author

vincentvanbush commented Jul 21, 2016

Well, with regard to testing Lit behaviour in multi-threaded environment, maybe we could try writing feature tests with Puma set as the underlying server and see if we can peek into what's been propagated to each process. I'm unsure if we will be able to have enough control over it, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants