Re: truncate randomly failing

Well, I still don't see how A is violated by a truncate (or by any other DDL, to that matter).
>
> Matthias and Jonathan pointed it out, but to be a bit more clear, it
> tries to maintain ACID by doing the commit, but after the commit there
> may be issues. Bug or design issues? Perhaps both. Erika's problem
> sure sounds like a bug, assuming it really happens to a single user.
> And I've seen similar things when I've been the only user on a new db.

Indeed, any DDL implicitly commits before and after itself (or rolls back if failed for some reason). This makes changes done by DDL itself pretty atomic. As of inability to rollback a truncate operation - can you roll back any other successful DDL? No, because it was successful - and it already committed all changes to the dictionary and related structures. If it was unsuccessful - it already rolled itself back. That's the way DDL works, and it works atomically even though it may look as though it doesn't - because it always commits before itself, then does its own transaction, and either commits or rolls back again depending on the outcome. As of Jonathan's example - indeed this may be a problem, but does it demonstrate a violation of any ACID letter? Session 1 waits for a lock on table, session 2 issues truncate over the table - truncate internally commits releasing all session 2 locks and session 1 acquires the lock it waits for, session 2 then attempts to acquire the lock, too, and fails - truncate never takes place. Where the atomicity is violated in this scenario?

As of 8i reference saying that "...because the information in the V$ views is dynamic, read consistency is not guaranteed for these views", I believe this statement only relates to *dynamic performance* views and not to dictionary views, which are pretty static and are always read-consistent.

-- 
Vladimir Zakharychev (bob@dpsp-yes.com)                http://www.dpsp-yes.com
Dynamic PSP(tm) - the first true RAD toolkit for Oracle-based internet applications.
All opinions are mine and do not necessarily go in line with those of my employer.