[Catalyst] flash with DBIC session storage

[J. Shirley]

On 7/27/07, Jonathan T. Rockway <jon at jrock.us> wrote:
> On Fri, Jul 27, 2007 at 06:11:03PM -0700, Mesdaq, Ali wrote:
> > I think in the case of the person who initially emailed the group the
> > problem is poor load testing. But it does bring up the point of better
> > handling of exception statements by DBIx.
>
> DBIx:: is a generic namespace for DBI extensions.  DBIx::Class is
> abbreviated as DBIC.  (This comes up a lot, I should add it to a FAQ
> or something.)
>
> > The DBIx::Class::ResultSet::find_or_create(): call should handle
> > this exception better because it can happen in tons of different
> > places and its not always an application or benchmarking issue.
>
> What do you think it should do?  create failed.  Only your app knows
> what to do in that situation.
>
> Maybe you are suggesting that errors be hidden so your app silently
> loses data?  I am not in favor of that.
>
> > In high load situations you WILL see this happen.
>
> I have a feeling that your app is broken then.  I often do dumbass
> load testing on my apps and don't have any problems with transactions
> failing unchecked.
>
> I really think you should read about transactional isolation and how
> deadlocks/conflicts are handled by your RDBMS.
>
> The Berkeley DB has really good documentation on both of these things,
> describing both theory and how to avoid common problems with the
> library itself.  SQLite's docs are also good.
>
>
> > To illustrate here is an example: Your DB has a first_name table to
> > store user first names You get a flood of new people registering and
> > you normalize their first names to get id's 2 Users have the first
> > name of Tom which does not exist yet You call
> > DBIx::Class::ResultSet::find_or_create(): Both calls detect the name
> > does not exist Both calls insert with one getting this error
> >
> > Now there is no real way to handle this in your app unless you do a lot
> > of concurrency checking or queuing of inserts.
>
> Rollback and try again.  Your DBMS' docs will tell you about the best
> strategy for dealing with this case.  I'm sure there's a good-enough
> generic solution... if someone knows it, I would like to hear.
>
> Anyway, you should probably continue this thread on the DBIC mailing
> list instead.  DBIC has *nothing* to do with Catalyst.
>
> Regards,
> Jonathan Rockway
>

Agreed on all counts, doubly so on moving to the DBIC mailing list.

If you believe that concurrency isn't handled properly in DBIC, I'm
sure several people would love to hear it.  I'm sure they'll
immediately shoot you down, though for the same reasons Jonathan
posted.

Here's a good test script that you can even port to DBIC that
demonstrates a concurrency bug in MySQL:
http://bugs.mysql.com/file.php?id=6906&text=1

-Jay

-- 
J. Shirley :: jshirley at gmail.com :: Killing two stones with one bird...
http://www.toeat.com