Forum OpenACS Q&A: duplicate key problem creating new users

Collapse
1: duplicate key problem creating new users
Posted by Kevin Murphy on 12/01/02 06:01 PM
I'm using OACS 4.5 with PG 7.1.3

I'm having difficulties creating new users via the admin interface.  Although the admin interface doesn't notice a problem and happily sends an email to the "new user", the new user is not actually created.  In the aolserver log I see this error: "
Cannot insert a duplicate key into unique index users_pk
DEBUG:  Last error occured while executing PL/pgSQL function acs_user__new"

Earlier I was able to successfully create two users via the admin interface.  I subsequently created dozens of persons who are not users via TCL.

I looked at various forum posts, but I wasn't very enlightened.

Before I dive in and start investigating ... does this ring a bell with anybody?

Thanks,
Kevin Murphy

Collapse
2: Re: duplicate key problem creating new users (response to 1)
Posted by russ m on 12/02/02 03:55 AM
/acs-admin/users/user-add pre-generates the user_id for the new account, so if you're getting there by hitting the back button, or if you're behind a cache, you may getting a stale "new" user_id. ACS seems to silently ignore the error when it attempts to create the new user in order to nicely handle the "user hit the submit button twice" case.

If you go to /acs-admin/users/user-add and force-reload the page, you should be right...

There have been a few threads about problems with OpenACS and caching lately - perhaps it would be worth changing the default master templates to make OpenACS less cacheable by default...

Collapse
3: Re: duplicate key problem creating new users (response to 1)
Posted by Simon at TCB on 12/02/02 11:40 AM
Or maybe we should consider a general rule whereby pages don't assigned new ids unless they are the same page thats going to do a database insert?

Ok that may mean wasting numbers from object_id_seq, but that hardly a big deal given that it'd take several lifetimes to run out of numebrs.

And also perhaps __new functions should, when approriate, generate a new id when there's conflict? Bit more case by case this one, but many __new's already do it, and as many don't. Is a general rule required?

Collapse
4: double-click protection (was duplicate key problem creating new users) (response to 1)
Posted by russ m on 12/02/02 12:17 PM
If the object_id is generated by the page that is doing the insert, we may as well let __new generate it. And as far as wasting object_ids goes, I'd think that's really a non-problem.

The reason for pre-allocating the object_id is to nicely handle the "clicked submit twice" case, but the standard ACS technique of silently ignoring the second insertion with any particular object_id does break down with users web-savvy enough to use the back button (which barely even counts as "web-savvy" these days).

Strictly speaking, if we're going to do double-click protection by silently ignoring duplicate inserts, we should make sure that it really is a duplicate insert. Likewise, you don't want to just go and generate a new object if you have a collision, otherwise the double-click protection goes away and you end up with many duplicate items created by people who habitually double-click on things.

Collapse
5: Re: double-click protection (was duplicate key problem creating new users) (response to 4)
Posted by Kevin Murphy on 12/02/02 03:27 PM
Thanks, gurus, for responding to this issue.  Personally I think this should be logged as a bug, even though, judging from the discussion, it has historically and slightly perversely been considered a feature.
Collapse
6: Re: duplicate key problem creating new users (response to 1)
Posted by Lars Pind on 12/02/02 05:20 PM
Yes, the standard way to do this, currently, would be to at least check that a user with the email given exists in the database, before silently assuming double-click.

This is related to the cross-site scripting stuff discussed in other threads, and I believe Branimir Dolicki and others have come up with an alternative implementation, though I don't recall the details just now.

/Lars