I understand that you want to stay flexible and make sure you don't
turn off your users. So the user completes the registration form
(including email) and posts to the server. The registration is
complete and the user can login. Your server sends the verification
email:
You can have some Quartz job that looks for accounts that have not
been verified and have them flagged for next login for the user to
check their email address or phone number and try again. I think that
the only time you run into this problem is when the user opens their
user profile after successfully registering and logging in and *then*
verifies via email or sms, right? If they had not completed the
registration form then you would not have sent the email yet.
If your workflow consistently generates opt locks, then you need to re-
think the flow. But if its not avoidable, then you will have to hold
the posted information in memory/session/whatever while you save your
form and then if the lock error occurs you have the new and old copy
and can merge them automatically or ask the user to merge them.
One thought: What generates the optimistic lock failure? The
verification post or just a random user profile save post?
On Jun 5, 2008, at 6:23 AM, OuterBound wrote:
Hi Dusty,
We designed application in a way that user can verify email at any
point of
time. Email verification is not mandatory but is good since we can
send
website update to verified users.
I don't want to stop user from fill in other details if email is not
verified since email might land up in bulk folder/user is lazy. I want
registration to complete first while user is at website. They can
login even
if email is not verified.
Besides there is a change email functionality. If they change email,
we send
mail to verify. Problem still persist if they are working on a form
and
click the link from their mail client.
We also do mobile verification where they send us an SMS, same
optimistic
locking failure happens.
Is it good idea to tell users to refill the form with database value
since
we tell them to do so that their email/mobile is verified while
they were
filling up the form :D sounds funny.
Right now I work around the problem with fetching the user from
database
during page rewind of any form so tapestry merges it right.
Ideally I would like to deal with this when there is an optimistic
lock
failure and without asking users since I already have my answers
dusty wrote:
So, in your use case, the original user sign-up form is still up in
the browser window when the user goes to their email, clicks the link
(launching a new window) -- updating the user record and then the
user
returns to the form that is open, makes a change and submits? That
would cause a opt lock failure.
When a user signs up, do you redirect to a page saying something like
"Hey, just sent you an email to make sure you are a real person.
etc"? Or are you just returning the form again? Redirecting to
another page would help since then the user would have to go edit
their profile to bring up the form, which is impossible since they
can't login until they are verified.
-D
On Jun 4, 2008, at 1:27 PM, Anil Sharma wrote:
I am building a web application using tapestry/spring/hibernate
based on
appfuse.
During signup process I send an email with a link to verify the
email
address and take user automatically to next step to fill another
form in the
browser.
When user clicks on the link in email, there is an database update
with
email verified flag marked as true and version incremented.
When user click mail link and afterwards submits the next form with
his
changes, there is optimistic locking failure thrown since version
has been
updated by his clicking mail link in separate browser window.
I want to handle this exception as to merge users changes as well as
mark
email verified flag as true.
I don't want to inform user about it since I know already clicking
on mail
link updated the version field and hence the conflict with
optimistic
locking failure
How to go about it??
Edit/Delete Message Reply With Quote Multi-Quote This Message Quick
reply to
this message
--
View this message in context:
http://www.nabble.com/Optimistic-Locking-Failure-Handling-tp17655867s2369p17655867.html
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Optimistic-Locking-Failure-Handling-tp17655867s2369p17669689.html
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
