Re^2: Sequences, last_insert_id, SQLite, and Oracle

This is no good if you have concurrent sessions both inserting into the same table. You have no way of knowing that in between when process A inserted into the table and when process A checked the last value of the sequence, that process B hadn't inserted a row and caused the sequence to jump.

The way to handle this is to catch the sequence value that was actually used by the trigger, atomically as part of the insert statement itself. Oracle DOES IN FACT provide a way of doing PRECISELY THAT. You can write an insert statement like "insert into foo ... returning id into ?", and then use in/out binding (see DBI docs for bind_param_inout) to catch the value that is spit out into that trailing bind value.

This method works, reliably. It is easy enough. None of the other methods in this thread do work reliably.

------------
:Wq
Not an editor command: Wq
[download]

Comment on Re^2: Sequences, last_insert_id, SQLite, and Oracle Download Code

Replies are listed 'Best First'.
Re^3: Sequences, last_insert_id, SQLite, and Oracle by sharkey (Scribe) on Jun 17, 2005 at 04:28 UTC
That is complete and utter misinformation. Fortunately Oracle has a much better grasp on concurrency issues than you do. Oracle sequences are designed to support heavy transactional loads. One thing they sacrifice for this is guaranteed serial-ness of the numbers. Each session gets its own cache of sequence numbers, so that it can avoid needing to lock the sequence every time you ask for a new number. The number you get from NEXTVAL will be the number you get from CURRVAL, and no other sessions can affect your value, because it is private to your session. You even get an error if you ask for the CURRVAL before you have asked for a NEXTVAL in this session.	[reply]

Replies are listed 'Best First'.

Re^3: Sequences, last_insert_id, SQLite, and Oracle
by sharkey (Scribe) on Jun 17, 2005 at 04:28 UTC

Fortunately Oracle has a much better grasp on concurrency issues than you do.

Oracle sequences are designed to support heavy transactional loads. One thing they sacrifice for this is guaranteed serial-ness of the numbers. Each session gets its own cache of sequence numbers, so that it can avoid needing to lock the sequence every time you ask for a new number.

The number you get from NEXTVAL will be the number you get from CURRVAL, and no other sessions can affect your value, because it is private to your session. You even get an error if you ask for the CURRVAL before you have asked for a NEXTVAL in this session.

[reply]