[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