[BULK] - Re: [Catalyst] flash with DBIC session storage

[Mesdaq, Ali]

This has been posted to the DBIC list for discussion last week. Jonathan
just to clarify I was not saying create() calls should not throw
exceptions I was saying find_or_create() should handle Duplicate Key
insert errors better since it supposedly should return an resultset to
you if it exists. But there is some discussion on the list about the
issue by people a lot smarter than me and I am sure they will have a
good solution or explanation for the problem.

Thanks,
------------------------------------------
Ali Mesdaq
Security Researcher II
Websense Security Labs
http://www.WebsenseSecurityLabs.com
------------------------------------------

-----Original Message-----
From: Jonathan T. Rockway [mailto:jon at jrock.us] 
Sent: Friday, July 27, 2007 8:57 PM
To: The elegant MVC web framework
Subject: [BULK] - Re: [Catalyst] flash with DBIC session storage

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

_______________________________________________
List: Catalyst at lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/