Updating row after insert that causes trigger

Question

Hi,
I have a table which one of the columns is a sequence number which each time a new row is written I want to automatically write to this sequence column the latest number (which is maintained using an Oracle sequence). I decided to use a trigger which works great:
CREATE OR REPLACE TRIGGER pre_insert_trg before insert ON INCOMING
for each row
BEGIN
SELECT INCOMING_SEQ.NEXTVAL
INTO :new.SEQ
FROM DUAL;
END;
The problem is I have many multi-threaded processes writing to this table and the sequence number gets allocated before the row is committed which means although thread 1 may write first it may commit after thread 2 which has a later sequence number which has the result that sequence number 2 may be shown before 1. The problem is much larger when dealing with many threads with 100's of messages a second and so I would prefer the seq to be added AFTER the insert (once committed), e.g.
CREATE OR REPLACE TRIGGER post_insert_trg after insert ON INCOMING
for each row
BEGIN
SELECT INCOMING_SEQ.NEXTVAL
INTO :new.SEQ
FROM DUAL;
END;
Trying to create this trigger results in a "ORA-04084: cannot change NEW values for this trigger type". Is there a way to update a column for the row which caused the trigger? If I try and remove the :new. I then get errors when inserting about mutating table (which I understand the DML locking but need a way round)
Many thanks,
John

Answer 1

Off hand I think the only way you can do what you say you want to do is to replace the sequence with a code table. A transaction locks the code table, gets the next value from it and unlocks the code table at the end of the transaction. This ensures that the sequence number is always assigned in transaction completion order (or rather the transactions always complete in sequence assigned order). It is basically what java does with its synchronize statement.
The only drawback with this approach is that it completely shags the performance of the sort of multi-threaded environment you've just described. :P
So you need to decide what's more important: having stuff inserted into a queue in sequence order or having a multi-threaded system running quickly. I really don't see how you can acheive what you're attempting in a genuinely concurrent environment; you'll have to introduce an artificial serialism (ie bottleneck) somewhere.
If you do crack this please tell me how: I would be interested in ordering multiple AQs in the fashion you described.
Cheers, APC