No such thing as a small change | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
"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 In reply to Re^4: Sequences, last_insert_id, SQLite, and Oracle
by jplindstrom
|
|