Re: double-clicking and DataContexts bound to the HttpSession

From: Bryan Lewis (brya..aine.rr.com)
Date: Thu Feb 17 2005 - 17:15:06 EST

  • Next message: Koen Segers: "Re: Extended class"

    We use the SynchronizerToken pattern in our Tapestry+Cayenne apps. The
    second submission would be stopped at the validation stage, and the user
    would've gotten a friendly error page saying something like, "You've
    resubmitted the form."

    http://www.junlu.com/msg/85270.html

    ----- Original Message -----
    From: "Mike Kienenberger" <mkienen..laska.net>
    To: <cayenne-use..bjectstyle.org>
    Sent: Thursday, February 17, 2005 3:04 PM
    Subject: double-clicking and DataContexts bound to the HttpSession

    > 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 - 17:15:17 EST