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

[Mesdaq, Ali]

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. 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. In high load
situations you WILL see this happen. 

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. 

Actually I should write a bug for this so the DBIx guys can check it
out.

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 5:27 PM
To: The elegant MVC web framework
Subject: [BULK] - Re: [BULK] - Re: [Catalyst] flash with DBIC session
storage

On Fri, Jul 27, 2007 at 11:57:01AM -0700, Mesdaq, Ali wrote:
> Are you sure that InnoDB would solve this issue? Even if just a row 
> was locked and you have 2 inserts at the exact same time how would 
> that resolve the issue?

One transaction would succeed and the other would fail.  If you want
different behavior, you'll have to change the isolation level (or
actualy, in this case, rethink your app).

It's more of an issue of this:

User visits page A.
User visits page B in another tab.
User submits form A.
User submits form B.
A updates the flash.
B updates the flash.
Page A2 loads with whatever flash won.
Page B2 loads with whatever flash won.

The point is that both transaction A and transaction B can't go through.
Web apps aren't designed to be hit concurrently by the same user; it
just doesn't make sense (or work) when you're keeping state.
One state has to win; this is what the DB error is telling you.

You could setup locks over [submit, update flash, display flash]:

User submits form A.
Form A gets the lock.
User submits form B.
B submission blocks waiting for the lock.
A updates the flash.
Page A2 loads.
A unlocks.
B gets the lock.
B updates the flash.
...

This adds a lot of complexity, though.  Is this really a problem that
your users experience, or is it an artifact of poor load testing
practices?

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/