Well, the MySQL protocol is a bugger of a protocol.
I recomend that you create a gen_server that deals
with the MySQL interaction. Then you provide an
atomic (gen_server:call) interface to that server, that
the rest of your system uses. This way, you won't get
any mixup of mysql messages. On the other hand your server
may become a bottle neck (eventhough I doubt that).
Alexander Williams wrote:
> If you folk read the main Erlang help list, you might have noticed I
> asked there about mysql module replacements/enhancements. (While the
> suggestion to use odbc was intriguing, I really would prefer/need an
> all Erlang solution.)
> But this isn't about that.
> I was going through the mysql module code and noticed that the
> fetches were being issued, reasonably, with the Pid of the calling
> process being sent along to reply. Seemed reasonable to me; I
> assumed that each yaws page reload should be getting a new pid, and
> my mingling of responses was some other glitch.
> Then I thought about what happens when you make assumptions. Then I
> ran some tests.
> On my installation of Yaws (latest release, Erlang 10-4), the Pid of
> the calling page render process flips back and forth between two
> different Pids. That's it.
> No /wonder/ the send is coming back confused and out of sync
> sometimes. Its expecting the Pid to be a relatively unique entity,
> and it instead is bipolar!
> So, here's the question: Is this a problem with my config, an
> intrinsic "feature" of Yaws, or a glitch in the mysql assumptions?
> Given my druthers, I'd /rather/ have the page requests be
> semi-unique (long-cycle, random in a large keyspace, whatever) to
> facilitate just such response patterns.
> Worst case I can just have the .yaws code spawn a process to do the
> mysql interrogation, which should reintroduce the proximate
> uniqueness of the Pid for the duration of the call need, but it
> seems vaguely awkward.