[erlang-questions] Writers Readers problem

[dmitry kolesnikov]

Hello,

With a registered process you have a single-server bottleneck, do not
keep all eggs in one basket. What I mean is a process per token...

In this respect, the process idles in memory unti it is consumed or
ttl expired. You have to protect data against OOM or node failure. In
this particular case for one-time token I would not see a strict
requirements for durability and recovery due to cost and system
complexity.

But if you are strict about durability then DHT/Chord type of
in-memory systems are required: mnesia, riak, etc.

Best Regards,
Dmitry >-|-|-*>


On 31.1.2012, at 17.12, Garrett Smith <g@REDACTED> wrote:

> On Tue, Jan 31, 2012 at 5:18 AM, Roberto Majadas Lopez
> <roberto.majadas@REDACTED> wrote:
>> 2012/1/30 Dmitry Kolesnikov <dmkolesnikov@REDACTED>
>>
>> The problem is that i've n process representing an user session, and the
>> token is like a "ticket" to authorize to take some information from the
>> server. The real user gets the token and goes to an http server (inside the
>> erlang app) a create one of the (m)-process. This process needs to check if
>> the token is valid or not. If is valid, the user can get the data and the
>> token is removed.
>
> This sounds like a registered process (e.g. gen_server) that manages
> the token. It's user facing API might look like this:
>
> acquire_token() -> {ok, Token} | timeout
> acquire_token(Timeout) -> {ok, Token} | timeout
> release_token(Token)
> is_token_valid(Token) -> boolean()
>
> The user processes would acquire a token and pass it to an agent,
> which would then validate it before proceeding. The agent could
> release the token when it was done with it.
>
> This scheme could be used for rate limiting, simple authorization, etc.
>
> This problem seems independent of persistence, independent of crash
> recovery. If you needed to recover token state from a crash, the
> process would need to save off its state somewhere (I typically use a
> single dets table per process) and look for that state on init.
>
> Garrett