Re: Multithreaded JDBC ORACLE apprlication problem

From: Justin Cave <jocave_at_yahoo.com>
Date: 29 Oct 2002 02:51:05 -0800
Message-ID: <233b7a65.0210290251.55ace0d8_at_posting.google.com>


bonny.rais_at_siemens.com.au (Bonny Rais) wrote in message news:<bd7f7b28.0210281543.384c349b_at_posting.google.com>...
>
> Application setup:
> an application server with multiple connection threads (typical
> configuration has 4 such threads) all waiting for requests to be
> dispatched.
>
> Background info:
> Threads start up OK, each opens a new connection to Oracle, which
> is confirmed using TOAD and looking at the currently open connections.
> Each connection is allocated its own connection id. Every connection
> uses the serializable transaction isolation level.

What you describe below sounds like the proper behavior for the serializable transaction isolation level. Unless there are significant additional constraints on you that are forcing you to use this level of isolation, I'd strongly consider using just the standard read committed isolation level.

Justin Cave  

> Every request issued to the application server, which uses one of
> these connections starts a transaction, performs whatever database
> operation then issues commit or rollback, depending on logic.
>
> Symptoms:
> Commit is not made visible to other database connections or the same
> database connection for subsequent database operation until a
> particular one of the connections happens to issue a commit.
> In particular, the following scenario describes the operations taken
> and the results:
>
> 1 conn1 issues an insert into a table and creates a new record.
> transaction committed
> 2 conn2 issues a select on the affected table but does not see the new
> record. conn2 commits
> 3 conn1 issues a select on the particular record but cannot see it.
> conn1 commits
> 4 conn4 issues a database operation on unrelated tables and commits.
> The new record is visible to all connections.
>
> More over, commit count in oracle does not increase for each of the
> first three operations,only
> on the fourth and increments by 1, not 4!
Received on Tue Oct 29 2002 - 11:51:05 CET

Original text of this message