Re: Usage of RowId...

From: Nuno Guerreiro <nuno-v-guerreiro_at_telecom.pt>
Date: 1998/04/17
Message-ID: <353818cd.65484061_at_news.telecom.pt>#1/1


On Thu, 16 Apr 1998 14:19:51 -0400, "Brian K. Lawton" <NOSPAM.Lawton_at_RDAConsultants.Com> wrote:

>When the database connection is persisted, I agree with everything Thomas
>and Nuno said. However, in a stateless environment, I fail to see how this
>will work. When a query is issued over the inter/intranet, there is no
>guarantee that as to what will happen next. The user may or may not issue
>an update. Furthermore, the query and the update will most likely both
>happen under separate database connections.
>

OK, I missed the point because I didn't realize that the connection was dropped immediately after a SQL statement was issued.

Sure that under this circumstances, you'll have to implement your own method of controlling concurrency.

Just one question: Will the client really be dropping the database connection after every single SQL statement? If so, be aware that you won't be benefitting from Oracle's transaction processing and that could seriously damage your database integrity. Let's take the following example:

I have two bank accounts (A1 and A2) on a bank and I must transfer $100 from A1 to A2. The whole transaction is composed by two operations: Subtract $100 from A1 and add $100 to A2, which turns out to be 2 SQL statements. If they occur in 2 different database sessions, then you must issue a COMMIT for each session. Imagine that immediately after the first session ends, the client cannot initiate the 2nd session (due to lost network connection, hardware failure, etc.).

You'd end up with an invalid database state.

Another question: Is it absolutely essential that the client connection is dropped after a statement is issued? I believe you could build a more stable and secure system with less careful planning if this wasn't a must.

Nuno Guerreiro Received on Fri Apr 17 1998 - 00:00:00 CEST

Original text of this message