in reply to Re^3: Sequences, last_insert_id, SQLite, and Oracle
in thread Sequences, last_insert_id, SQLite, and Oracle

"Also, "select ... for update" does nothing to deal with race-conditions on *insert* (which is the case here)"

Of course it does, the "select for update" followed by the upate was for getting a unique sequence number for the PK in the insert.

The next insert won't happen until the first transaction is comitted, since the second "select for update" will block until then (at least that's the locking semantics in Oracle).

This is also precicely why this is bad for concurrency.

Not only are the inserts serialized, the small sequence number table probably fits in a data block or two and is bound to incur a huge amount of block contention for _all_ tables that get their PK like this.

That's why it's a good idea to keep the database abstraction on a higher level, so that Oracle specific sequences can be used on Oracle, etc.

DBI is very useful to abstract away connectivity issues, but it would be nice to have a standard way to manage SQL dialect issues as well, like date formats, limit, PK generation and stuff like that.

/J

  • Comment on Re^4: Sequences, last_insert_id, SQLite, and Oracle

Replies are listed 'Best First'.
Re^5: Sequences, last_insert_id, SQLite, and Oracle
by etcshadow (Priest) on Jun 15, 2005 at 19:45 UTC
    Well, if by "sequence" you meant "table in which you store a deliberately incremented value", then yes, with all the points you mentioned. The problem with that is, as you mentioned, all the ridiculous amounts of contention you get (and setting yourself up for big problems with deadlocking as a result). Of course, when you say "sequence" in the context of auto-increment tables, specifically in an oracle-specific context, it's pretty fair to assume that "sequence" means "oracle sequence", so I don't feel so bad for misinterpretting :-)

    In one of my other replies in this thread I mentioned how you could do that etc, etc. The "right way" would be, in fact, to implement your own sequence by way of autonomous subtransactions (another oracle-specific feature... not to say that no other RDBMSs support them, but certainly not all RDBMSs support them).

    ------------ :Wq Not an editor command: Wq