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
Copy file name to clipboardExpand all lines: docs/content/docs/options.md
+26Lines changed: 26 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -121,6 +121,32 @@ The maximum amount of time (in milliseconds) that the in-memory lock for [stampe
121
121
122
122
This is usually not needed, but can provide an extra layer of protection against theoretical deadlocks.
123
123
124
+
### `lockManager`
125
+
126
+
Default: built-in in-memory lock manager.
127
+
128
+
Levels: `global`
129
+
130
+
A custom lock manager instance.
131
+
132
+
This lock manager is used for stampede protection and file driver writes.
133
+
134
+
`LockManager` must return a lock compatible with `MutexInterface` from `async-mutex`. Bentocache exports `LockHandle` and `LockReleaser` as aliases for `MutexInterface` and `MutexInterface.Releaser`.
Copy file name to clipboardExpand all lines: docs/content/docs/stampede_protection.md
+8Lines changed: 8 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -54,3 +54,11 @@ Well, in truth, this is not really a problem. Indeed, there will be more than on
54
54
Given the same scenario with the 10k users. Imagine that your application is running in cluster mode with PM2 and you have 10 instances of your app. Also, imagine that the 10k requests are distributed equally across the 10 instances.
55
55
56
56
This results in 1k requests per instance. And so, it will lead to **10 queries to the database instead of 10k**, with the help of our protection.
57
+
58
+
## Shared locks
59
+
60
+
BentoCache allows you to use custom lock manager so you can implement **shared** locks .
61
+
62
+
For example, you can implement lock manager which uses patterns like [Redis distributed locks](https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/) where locks are created in L2 storage and shared across all application instances and don’t have process instance limitations.
63
+
64
+
In multi-instance applications scenario, this will lead to **1 query to database instead of 10k**.
0 commit comments