Re: Serializable transactions get rolled back while there are no othertransactions running?!

Jonathan Lewis wrote:

> Apparently, this one will be fixed in Oracle 11
> (yes, really, that wasn't a joke).
>
>
> Could you clarify what environment or feature
> you are thinking of when you comment on the
> "per-table configured memory " and the need
> to configure more of it.

inittrans

>
>
> Regarding:
>

>>Any data that is read by a serializable tx can be altered and committed by

>>tx before the first one completes, and if the first tx rereads the changed
>>data it will still see the old values, even though the real data has been
>>changed.

What most people expect is that when their query reads data, that it is the real data. Many people assume that the data they read will not/must not change until the end of their transaction. Ultimately oracle implemented select FOR UPDATE to provide this functionality for those that demamded it.

> I believe the intent of serializability is that the result of running
> the transactions concurrently should be equivalent to at least
> one order for running the transaction serially.

true.

> So a transaction
> should never see changes made by any other transaction or there
> will never be a serial order that could get the same result.

True, but 'should never see' is not what some people want or expect. They want 'should never happen'.
Joe
>
>
Received on Sun Jun 20 2004 - 23:59:28 CDT