<div dir="ltr">On Tue, Oct 29, 2013 at 4:28 PM, Charles Irvine <span dir="ltr"><<a href="mailto:chuck.irvine@icloud.com" target="_blank">chuck.irvine@icloud.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div>I do realize that workflow state will need to be stored to a database.</div></div></blockquote><div><br></div><div>Usually you want to choose between storing state in a process or in a database.  The only time you'd want to do both is for caching (in which case you would either have many short-lived processes or a few long-lived processes).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I don't envision much in the way of client sessions.</div></div></blockquote><div>
<br></div><div>If you have clients connecting over TCP or something you definitely want per-client processes (even if they only process one request and then end the session).  Doing this will simplify your code flow dramatically.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>The thing that will drive the system are task completions. Task completion adds information to the workflow context and generates new tasks to be completed.</div>
</div></blockquote><div><br></div><div>This is the biggest decision to make IMO with respect to process model.  Depending on the complexity of this process, you could either:</div><div><br></div><div>1) perform a mnesia transaction in the client process</div>
<div>2) start a process to perform the mnesia transaction (and maybe other actions)</div><div>3) call a long-lived process (a gen_server) to perform the mnesia transaction (and maybe other actions that must be synchronized)</div>
</div>