|Sorry, but I downvoted this - for a number of reasons:
* It requires an additional two physical i/o calls - to get the latest value, and to update it afterwards
* It requires that you have a READ lock on the sequence table; to avoid duplicates, you must read the value, insert the new record, and update it all within a transaction and without allowing any other process to read the value. At best this requires an additional lock, but at worst - if poorly coded - can leave that lock in place for a prolonged period and cause a major performance bottleneck
* It creates sequential user ids; presumably you have secure password / two-factor authentication, but by using sequential numeric ids you're making it very easy for hackers as they can just generate sequential hacks on the id
If sequential IDs isn't an issue (and it may not be in all cases) the simplest thing is to use an auto-increment field and return the new ID from the insert statement. Any decent DBMS will keep track without issue. In the event of a transaction rollback there may be a "missing" ID but that shouldn't (be allowed) to cause your application a problem.
A method I use when generating IDs is to use a GUID value (or sometimes a truncated portion of a GUID) and simply INSERT into the table. With a unique key on the ID, then in the vanishingly small likelihood of a duplicate, the INSERT will fail. Catch the "duplicate record" exception, replace the ID with a new GUID and insert again. The performance hit from that is miniscule as it will probably never ever happen.