I just had a non-fun event.
One of our web users resubmitted a form while applying for an account.
What happened was that the first submit paused 30 seconds while sending out
an email message.
I send out an activation message before I commit a new account creation.
However, the impatient user clicked submit again after 10 seconds, starting
the process a second time.
So the 2nd request goes through, adds a second user object (along with
second copies other garbage) to the context, sends the email without
incident (obviously it was a temporary network timeout on the first
request), then commits both the first and second set of each object.
Then the first request recovers, and commits, but now has an empty
DataContext.
So now I'm trying to decide how to handle this.
I can check in my getDefaultContext() if the DataContext is dirty and then
return a new DataContext, but that doesn't really solve the problem. In
that case, the 2nd request would have still created a second copy of the
objects and commited only the second copy, and the first request would have
still committed the first copy, so I'd still end up in the same situation.
I can probably deal with this specific problem by detecting a double-click
event and handling it differently.
However, I'm now a little paranoid about sharing a DataContext within the
same HttpSession. It never occurred to me before that two threads might be
operating on the same HttpSession DataContext at the same time. Am I
overlooking something?
Do I need to somehow lock my DataContext on session request receive and
unlock it on session response send? This is sounding depressingly like
WebObjects 5.0/5.1 without the added safety of serialized access.
Or maybe I just need to force all access to a session DataContext to be
serialized.
-Mike
This archive was generated by hypermail 2.0.0 : Thu Feb 17 2005 - 15:03:59 EST