Re: Article about supposed "murky" future for Oracle

From: Jim Kennedy <kennedy-downwithspammersfamily_at_attbi.net>
Date: Thu, 01 Apr 2004 03:10:54 GMT
Message-ID: <2LLac.151387$_w.1686891@attbi_s53>

"rkusenet" <rkusenet_at_sympatico.ca> wrote in message

news:c4fsrd$2giq6n$1_at_ID-75254.news.uni-berlin.de...
> "Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message
news:1080782348.656876_at_yasure...

> > rkusenet wrote:
> >
> > > "Daniel Morgan" <damorgan_at_x.washington.edu> wrote
> > >
> > >
> > >>Depends on whether the architecture is such that you have minimized
the
> > >>possibility of multiple transactions attempting to update the same row
> > >>at essentially the same time.
> > >
> > >
> > > if the above is true, then thank god we are not using oracle bcos we
> > > have multiple sessions trying to grab same row from a queue table.
> > >
> > >
> > >>We all design to maximize our strengths
> > >>and to minimize our weaknesses: Or at least we should.
> > >
> > >
> > > well said.
> >
> > Thanks. But then I could point out that if you did have Oracle
> > you'd have the DBMS_AQ built-in package and Oracle's Advanced
> > Queueing so the issue you describe wouldn't exist.

>
> No comments since I don't know AQ packages. Are they equivalent
> of database tables. Are they as simple to program as writing a SQL.
> Can data be loaded into a datamart/datawarehouse. And above al
> is that a separate product from Oracle and built into the database
> server.
>
>
> Speaking for myself I like using database tables for
> work flow. It is a proven technology and IMO no database other
> informix work as well. Reason being that informix concept of non
> logged database is unique. It virtually eliminates any disk activity
> except writing to physical once per checkpoint. Of course you will
> lose data if a crash happens, but then u don't care either.
>
> We use both logged and unlogged database. Where we need to log
> information and where we need concurrent access, we use logged database.
>
> The only advantage I see of using a Queue series is that the application
> process need not poll the table. They can be called on events. But then
> with multiple processes polling the work flow table, the wait time is
> almost negligible. Actually we can convert it into an event by attaching
> a table trigger to a C code.
>
> I have been told that Oracle's concept of lock management is to write
> the lock information in the data block itself, instead of centralized
> lock manager. That means a SELECT FOR UPDATE will be two writes. One for
> the lock and one for the actual write of the data. Not OK for us
> in the given scenario.
>
>
>
>
>
>
>
>

It is very interesting how in one breath you claim to know almost nothing about Oracle and in the next make assumptions that are unfounded.

Geezzee, how biased can you get.
Jim Received on Wed Mar 31 2004 - 21:10:54 CST