Locking on UPDATES

I have a question on the type of lock placed on a row during an UPDATE statement that doesn't use a cursor. I come from a Sybase background and want to generate a simple surrogate primary key using a next key table. I don't want to use rowids because the first part of the primary key will be a number used as part of an identifier. The next key table looks like this programnumber(int) nextkey(int) and would have data like row 1 101, 3 row 2 205, 4 so if you wanted to generate a new key to insert into the main table, and it had to do with program 101, you'd get 1014, then 1015, etc. And if it was for program 205, you'd get 2055, 2056, etc. I read Sybase's white paper on this, and basically you can do an update with a select of the nextkey value embedded in it. This prevents another process from reading the nextkey, since the update has an exclusive lock. I want to do the same thing using Informix, but am a little confused about shared, promotable, and exclusive locks. If I do the UPDATE statement and there is already a shared loack on the row, a promotable lock will be placed on the row. Can another process do a SELECT on the row, placing a second shared lock on the row, and prevent the promotable lock from being promoted to an exclusive lock? Could this go on indefinitely. Also, I assume that I should set the isolation level to repeatable read for this. Is this correct? Thanks for your help. -Clay Amerault