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
Now that we're no longer using distribution via Mnesia, we should jump to using straight ETS tables.
This presents a challenge, because of transaction support, which we don't want to remove - so we need an implementation which functions in the same way (although we don't need to provide abort/1 I think), without using Mnesia.
This will take shape by using a special lock table per cache, which allows for either a global lock, or key locks. If the key being operated on is locked, then calls to that key just sit until it's ready. This needs heavy documentation to make it clear that this will block all calls (if you block the table, obviously).
There's naturally a slight performance hit to this even if you're not using transactions. Due to this, transactions should be a flag you can turn on or off. If they're disabled, then you can't use them (and thus there's zero hit). If it's enabled, you can use them, with the understanding that there's likely a couple of microseconds perf hit on every command. I haven't yet decided whether it should be enabled by default or not (I'm leaning towards not).
It's very possible that this won't ever be done/merged, due to complexity. Also, the above is a scramble of thoughts in my head - I'll neaten up the notes here once it's more solid.
The text was updated successfully, but these errors were encountered:
Now that we're no longer using distribution via Mnesia, we should jump to using straight ETS tables.
This presents a challenge, because of transaction support, which we don't want to remove - so we need an implementation which functions in the same way (although we don't need to provide
abort/1
I think), without using Mnesia.This will take shape by using a special lock table per cache, which allows for either a global lock, or key locks. If the key being operated on is locked, then calls to that key just sit until it's ready. This needs heavy documentation to make it clear that this will block all calls (if you block the table, obviously).
There's naturally a slight performance hit to this even if you're not using transactions. Due to this, transactions should be a flag you can turn on or off. If they're disabled, then you can't use them (and thus there's zero hit). If it's enabled, you can use them, with the understanding that there's likely a couple of microseconds perf hit on every command. I haven't yet decided whether it should be enabled by default or not (I'm leaning towards not).
It's very possible that this won't ever be done/merged, due to complexity. Also, the above is a scramble of thoughts in my head - I'll neaten up the notes here once it's more solid.
The text was updated successfully, but these errors were encountered: