Re^4: 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.

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 15:45 UTC

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
[download]

[reply]
[d/l]


Syntactic Confectionery Delight
	PerlMonks

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

This is an archived low-energy page for bots and other anonmyous visitors. Please sign up if you are a human and want to interact.