Re: No future for DB2

> 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.

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. My interpretation of the article if that is what it was is that DB2 is not penetrating very far in the unix world. It obviously will not EVER go away too many big shops running it on the mainframe. And it has certainly gotten at least limited traction in the unix world, some of my good friends and former colleagues are supporting SAP at a big chemical manufacturer running DB2 on unix. It's a good product but so much depends on momentum and marketing. Just my opinion.

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? Informix supports versioning columns which can be used by the app to prevent overwriting other users changes across DB transaction boundaries. MS SQL server has a somewhat similar approach and even buried optimistic locking into the cursor logic (not applicable in a stateless enviroment (no cursor open). I see tha value of snapshot isolation for certain purposes. I don't see it for a 3 tier web application.... Thoughts? Cheers Serge -- Serge Rielau DB2 SQL Compiler Development IBM Toronto Lab

"hpuxrac" <johnbhurley@sbcglobal.net> wrote in message news:1122460910.114919.56460@f14g2000cwb.googlegroups.com... > 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. > > > My interpretation of the article if that is what it was is that DB2 is > not penetrating very far in the unix world. > > It obviously will not EVER go away too many big shops running it on the > mainframe. > > And it has certainly gotten at least limited traction in the unix > world, some of my good friends and former colleagues are supporting SAP > at a big chemical manufacturer running DB2 on unix. If only IBM already had a database product hugely respected in the UNIX market, and in fact designed specifically *for* that market, eh?

Serge Rielau wrote: > I see tha value of snapshot isolation for certain purposes. I don't see > it for a 3 tier web application.... > > Thoughts? I'm with you here. But we'll be enlightened, I'm sure.

Captain Pedantic wrote: > > If only IBM already had a database product hugely respected in the UNIX > market, and in fact designed specifically *for* that market, eh? You know: from the above, to IBM buying MySQL and re-labeling it as "common code base DB2", there is only a very little step...

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

>> If only IBM already had a database product hugely respected in the UNIX >> market, and in fact designed specifically *for* that market, eh? 4 in the top 9, including #1: http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=noncluster&version=5&currencyID=0 Cheapest Linux result: http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp?resulttype=all&version=5&currencyID=1 17 of 42 results are DB2, including 4 of 5 first place results: http://www.tpc.org/tpch/results/tpch_perf_results.asp?resulttype=&version=2 Seems like the DB2 design gives decent performance on UNIX, Linix and Windows.

Noons wrote: > Captain Pedantic wrote: > >>If only IBM already had a database product hugely respected in the UNIX >>market, and in fact designed specifically *for* that market, eh? > > > You know: from the above, to IBM buying MySQL and re-labeling > it as "common code base DB2", there is only a very little step... > Informix Standard Engine **IS** the equivalent product to compete directly with MySQL, but apparently nobody at Informix or IBM ever figured that one out--despite the known clues, such as MyISAM tables, etc etc. I was told personally by an Informix marketing exec that they "couldn't compete with MySQL", despite at the time ( 1999-2000 ) Informix was going down in flames. They opted to buy the racing team with their marketing budget, instead of promoting any of their products. The racing team really helped get the message across. Dumb fucks. Now it's too late, MySQL is the king in the ISAM space, period, on Linux. But of course IBM is more interested in the Java space, thusly this is why Cloudscape is given so much attention despite the fact that there are hardly any Java applications outside corporate environments, or installation programs. :-) When MySQL becomes enough of a threat IBM might pull its head out and rethink SE as an open source alternative to MySQL. But then again I doubt that will happen.