<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 1/28/12 4:18 PM, Matthew Evans wrote:
    <blockquote cite="mid:SNT125-W453262C5564166AA7FA8549C8F0@phx.gbl"
      type="cite">
      <style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
      <div dir="ltr">
        <br>
        <div>The obvious, and maybe non-OTP, answer is to hold some of
          this state information in a public or protected named ETS
          table that your clients read from directly. A single
          gen_server can still own and write to that ETS table. </div>
        <br>
      </div>
    </blockquote>
    This would be my first idea. Create an ETS table being protected.
    Writes to the table goes through the gen_server,<br>
    <br>
    -export([write/1, read/1]).<br>
    <br>
    write(Obj) -><br>
      call({write, Obj}).<br>
    <br>
    call(M) -><br>
      gen_server:call(?SERVER, M, infinity).<br>
    <br>
    but reads happen in the calling process of the API and does not go
    through the gen_server at all,<br>
    <br>
    read(Key) -><br>
      case ets:lookup(?TAB, Key) of<br>
        [] -> not_found;<br>
        [_|_] = Objects -> {ok, Objects}<br>
      end.<br>
    <br>
    Creating the table with {read_concurrency, true} as the option will
    probably speed up reads by quite a bit as well. It is probably going
    to be a lot faster than having all caching reads going through that
    single point of contention. Chances are that just breaking parts of
    the chain is enough to improve the performance of the system.<br>
    <pre class="moz-signature" cols="72">-- 
Jesper Louis Andersen
  Erlang Solutions Ltd., Copenhagen, DK</pre>
  </body>
</html>