[erlang-questions] Erlang processes and state management design
Bengt Kleberg
bengt.kleberg@REDACTED
Wed Oct 24 12:22:20 CEST 2007
greetings,
the first 3 solutions will be gone after the process dies. ets tables
are garbage collected when their ''owning process'' dies.
i would recommend 1 until you get > 1000 items per process.
or you could start with 1. keep the adding/removing/extracting hidden in
a module and then switch to 3 using another module with the same name if
you run into problems.
bengt
Those were the days...
EPO guidelines 1978: "If the contribution to the known art resides
solely in a computer program then the subject matter is not
patentable in whatever manner it may be presented in the claims."
On 2007-10-24 12:00, Alexander Lamb wrote:
> Hello again,
>
> So, I am gradually understanding the design philosophy of an Erlang
> application.
> On the one hand, functionnal programming is about having no state.
> However, in the situation of a Web application, you obviously need to
> keep some state otherwise you are back to PhP style (in the sense you
> are recalculating everything at each request).
>
> I went back to Joe's book and read again the chapter on processes. And,
> as someone suggested earlier, I realized the state of an Erlang program
> can actually be kept in a process. So when designing an application, you
> indeed model the processes, then the state of the processes, then the
> messages.
>
> So for example, if I create a process for each user who logs in to a
> program. Upon creation of the process I could fetch all the features and
> worklists the user has, then keep them in his process until he logs out
> (or after a given long timeout).
>
> I can do that for every task which needs to keep a state between requests.
>
> Therefore, I have a question: where is it usuall or reasonnable to keep
> the state of a process?
>
> 1) in the parameters of the function we spawn
> 2) in the process dictionnary
> 3) in an ETS structure
> 4) in a in-memory mnesia structure
>
> I suppose it really depends on the amount of data and how it will be
> modified (and if we want to keep persistent some session data after the
> process is killed).
>
> Tell me if I am wrong, but the first two solutions will put data on the
> process stack and will be destroyed when the process is killed. The two
> other solutions will have to be cleaned out when the process is killed.
>
> Are there some guidelines?
>
> For a user process, I might have 30 or 40 features in a list, some
> values about his account, etc...
> For a process managing (for example) browsing patients in a list, I will
> have the list of patients with the visits for the currently selected
> patient, etc...
>
> Thanks for any hints!
>
> Alex
> --
> Alexander Lamb
> Founding Associate
> RODANOTECH Sàrl
>
> 4 ch. de la Tour de Champel
> 1206 Geneva
> Switzerland
>
> Tel: 022 347 77 37
> Fax: 022 347 77 38
>
> http://www.rodanotech.ch
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list