You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For now, there are some unknown scalability bottlenecks:
When trying to commit to the global timeline log, multiple processes might result in contention of the log tail.
In a strict mode when every process might apply the newest log entries detected in every read operation: once a process publishes its transaction by committing it to the global timeline log, other processes would see it and try to read this log and apply it. This would cause a huge amount of traffic to read the cacheline that holding the log entries.
1 is yet an open question. One possible solution is to introduce partial ordering, but might be too complicated and out of the scope.
2 is possible to alleviate: once a process commits its log entries to the global timeline, it prefers to use another cacheline to write its next log entries. This will leave the previous cacheline holding the log entries untouched and shared-read by other processes.
The text was updated successfully, but these errors were encountered:
For now, there are some unknown scalability bottlenecks:
1 is yet an open question. One possible solution is to introduce partial ordering, but might be too complicated and out of the scope.
2 is possible to alleviate: once a process commits its log entries to the global timeline, it prefers to use another cacheline to write its next log entries. This will leave the previous cacheline holding the log entries untouched and shared-read by other processes.
The text was updated successfully, but these errors were encountered: