Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: "Transactions are bad, real bad" - discuss

Re: "Transactions are bad, real bad" - discuss

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Mon, 12 May 2003 18:03:02 +0100
Message-ID: <b9ok85$2a8k$1@gazette.almaden.ibm.com>


"Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:b9oh42$lgn1j$1_at_ID-152540.news.dfncis.de... [snip]
> Here's another point: you want to isolate computationally expensive
> processes from the core RDBMS functions.
>
> You want to isolate high-risk computations from the core RDBMS.
>
> In real world computations fial, and sometimes they fail horribly. If
> for nothing else than for the necessity to integrate third party
> packages, it's always the thrid party and not your code you know :)
>

[snip]
>
> So even if you give a more expressive language to power users to create
> user defined types and operators and what not, from a "software
> architecture" point of view, building all your important computations
> under the RDBMS umbrella and letting clients only do the UI rendering
> job ( at least this much I understood from your vision) is an absolute
> no go.

You characterisation of my vision is not totally off mark, but I don't see how you conclude that it is a no go.

If you are saying that certain database updates would need to be integrated into 'real world' events and that these events can fail or can take a long time to occur, then indeed I would want to isolate them from some 'core' database that users have free and full access to. The following example outlines one more strand of my proposal.

Say we want to build a database centric Instant Messaging system. We create a relvar such as

CREATE TABLE Messages(

    Sender User_Id CHECK (Sender = CURRENT USER),     Recipient User_id,
    Sent TIMESTAMP,
    Message VARCHAR(2Mb)
)

The intention is that any user wishing to send an IM simply inserts rows into this table using whatever interface they so choose.

BTW In this example, I ignore any robustness rules that would be highly advisable to prevent misusage. E.g. rules such as the following might need to be declared to the DBMS "users can only broadcast a single message to 20 users or less at one time" and "users can only average 100 messages per minute, with no more than 20 messages in any half second".

Now any individual instant message might fail to reach it's intended target - the user logs off and such events are only reported to the DBMS asynchronously, or a network failure occurs say. For any failed message, the corresponding tuple in the Message table would need to be 'rolled back'. I do not feel that this is acceptable. Therefore I would propose the following alternative design:

CREATE TABLE Message_Requests(

    Sender User_Id CHECK (Sender = CURRENT USER),     Recipient User_id,
    Requested TIMESTAMP,
    Message VARCHAR(2Mb)
)
;
CREATE TABLE Messages_Send(

    Sender User_Id,
    Recipient User_id,
    Requested TIMESTAMP,
    Sent TIMESTAMP,
)
;

In this design, only the Message_Requests table would be available for update by users. A *daemon* user would be defined in the database environment whose sole job would be to take every Message_Request and attempt to send it to the recipient user. If it succeeds then Messages_Send is updated by the daemon.

This isolates users from the failure possibilities inherent in the 'real world'. Their updates to Message_Requests will *always* succeed baring any constraint violations (that BTW are *all* visible to the users via the DBMS catalog), and any general system failure of the DBMS before an update was made persistent (i.e. logged).

In such a way I see an absolute GO GO for isolating the users database view from high-risk and computationally expensive processes.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Mon May 12 2003 - 12:03:02 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US