Re: Stateless clients and locking schemes (or rather isolation levels)

Serge Rielau wrote:

> Superboer wrote:
> >>This is a funny way of looking at. Obviously Oracle's none locking
> >>engine is perfectly suited to scaling multi user applications,
> >>particularly when most people are developing for stateless clients.
>
> > ahum does the above explain why informix was faster on a 5 times
> > smaller machine then obstacle...????
>
> > Superboer.
>
> Changed the subject lines and following up on what Knut started.
>
> How does Oracles snapshot isolation help with stateless clients.
> To the best of my knowledge snapshot semantics only operate on either a
> statement or a transaction level. In a stateless scenario I'd assume
> that teh application transaction covers at least two database
> transactions. A read phase wher the resultset is displayed at the client
> and a separate write phase where the modified data is written back.
> How does snapshot isolation help here?

I did not mean that to read the way it does, it is sloppy and not the point I was trying to make. My main point was contained in the full quote.

> This is a funny way of looking at. Obviously Oracle's none locking
> engine is perfectly suited to scaling multi user applications,
> particularly when most people are developing for stateless clients.
> The fact that developers have to go through the same gyrations for
> most other databases, copying data to private sessions to avoid locks,

What I was trying to get across was that it appears to me that copying data to a private area in a session, usually a temporary table, is a technique that can be employed in a locking database by an application to provide a read consistent view of the data when needed. I think this adds complexity to the application and not having to do it because the database does it for me is a real benefit. The fact that I imagine this would be more complex when state is not maintained was an aside that in retrospect was not necessary and in fact detracted from the point I was trying to make.

Sorry.

I also apologize in advance if I have misrepresented the purpose of temporary tables, as I have not used them in this way myself. A separate response to my earlier post suggested they were being used to break a query down into sub components for performance reasons.

-- 
MJB