| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> c.d.o.server -> Re: JDBC connection transactions
Hi,
look for 'serializable transactions' - this is probably what you want.
Performance-wise this is a very BAD thing to do, so avoid it at (almost)
all cost.
I have never heard of anyone who is actually using this for a production
system of reasonable size. (number of concurrent users that is, the
amount of data probably does not matter)
Actually there is a method in the jdbc driver spec that lets you set this connection property.
Karsten
In article <90rnut$a64$1_at_nnrp1.deja.com>,
Alex Filonov <afilonov_at_pro-ns.net> wrote:
> 1. I'd recommend you to read Oracle Concepts manual before
implementing
> any of such things.
> 2. Transaction starts when you run any SQL statement which changes
> any of tables. It ends either with commit command or with rollback
> command. So, if you have autocommit off, everything between first
> insert/update/delete statement and commit/rollback is one transaction.
> You can successfully roll back all statements in this transaction with
> rollback statement.
> 3. Queries do not create transaction!
>
> In article <90r2vn$nor$1_at_nnrp1.deja.com>,
> seanldus_at_my-deja.com wrote:
> > I need to accomplish a number of related select/insert
statements(about
> > 10 or 12 distinct queries most on seperate tables) these are all
> > related and if one fails I need to roll all the others back.
> >
> > This is a servlet environment written in java. It seems to me that
I
> > could implament one of a number of standards. I could get a non-
> > autocommitting connection and pass it from transaction to
transaction,
> > rolling back or commiting as needed. I could also create the entire
> > set of queries as one stored procedure. or I could do a combination
of
> > the two(this is what I am doing now but it seems problematic because
> > the stored procedures that do part of the work will commit on
> > finishing, thus making any rollback back in the java layer useless)
> >
> > the problem with going to the database 10 or 12 times per each one
of
> > these transactions is just that going to the database 10 or 12
times
> > per each one of these transactions.
> >
> > I wondered if there is a standard way that people handle this. Or
if
> > anyone has any tricks/places to look for reading, etc.
> >
> > Thanks in advance
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com
http://www.deja.com/
Received on Wed Dec 13 2000 - 10:36:25 CST
![]() |
![]() |