From version < 1.5 >
edited by Guillaume Delhumeau
on 2019/03/06 15:06
To version < 1.6 >
edited by Guillaume Delhumeau
on 2019/03/06 15:08
< >
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -30,13 +30,15 @@
30 30  D. The same event is stored multiple times in the database, so it continuously fill the same CompositeEvent.
31 31  E. There is a bug in the recursion so the database always return the same results (but it would mean we have an infinite loop, so it would crash).
32 32  
33 -== ==
33 +== Solution 1 - A: Add a timeout to the query ==
34 34  
35 +To avoid an infinite loop
36 +
35 35  = Problem 2: Notifications are computed each time a page is loaded =
36 36  
37 37  There is absolutely no cache mechanism. So, even if the query to fetch the notifications is long, it will be re-executed the next time a user loads a page.
38 38  
39 -== Solution 2-A: Create a memory cache ==
41 +== Solution 2 - A: Create a memory cache ==
40 40  
41 41  For each user, we could have a cache that store all the notifications that were returned during the last execution. This would be cleared:
42 42  
... ... @@ -44,11 +44,11 @@
44 44  * after a certain period of time
45 45  
46 46  (((
47 -== Solution 2-B: Create an "evolving" memory cache ==
49 +== Solution 2 - B: Create an "evolving" memory cache ==
48 48  
49 49  Same than 2-A, but when a new event is triggered, the cache would not be cleared. Instead, the new event will be considered for each user, and added the cache if the event is not filtered by the user preferences.
50 50  
51 -== Solution 2-C: Store in a permanent storage the notifications for each user ==
53 +== Solution 2 - C: Store in a permanent storage the notifications for each user ==
52 52  
53 53  This title is not exactly what I meant. The idea is not to store each notification in a table (the event is already in the event stream store), but the "read" status of each event for each user, **when the event is recorded**.
54 54  
... ... @@ -73,6 +73,7 @@
73 73  * On a wiki with a very large number of users, it means we would need to write a lot of lines in the "Event Status" table every time an event is triggered.
74 74  * Since the filters need to be computed for each individual user, this process can take a lot of time, and it must be performed asynchronously.
75 75  * "Event Status" are generated for users who never goes to the wikis, which is a waste of resource.
78 +* The "Event Status" table should probably be cleaned regularly to avoid having too much data, meaning some precious notifications could be lost while a user is absent (like a 2 weeks holidays).
76 76  * This mechanism cannot be applied for the Notifications Macro (that was designed to replace the Activity Stream), so it means both mechanism should co-exists.
77 77  
78 78  (((

Get Connected