If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

>Could it be caused by improper configuration ?
ROLLBACK does not happen automagically.
I suspect improperly coded application.
Is application written in Java?

You can lead some folks to knowledge, but you can not make them think.
The average person thinks he's above average!
For most folks, they don't know, what they don't know.
Good judgement comes from experience. Experience comes from bad judgement.

I encountered 1 Java application which did
SELECT SYSDATE INTO TIME_TEMP FROM DUAL;
ROLLBACK;
before issuing every valid SQL "just to be sure connection & Oracle were working".
Why anyone thought a ROLLBACK of a SELECT was ever appropriate, boggled my mind.

ROLLBACK is/are application induced activity.

You can lead some folks to knowledge, but you can not make them think.
The average person thinks he's above average!
For most folks, they don't know, what they don't know.
Good judgement comes from experience. Experience comes from bad judgement.

I encountered 1 Java application which did
SELECT SYSDATE INTO TIME_TEMP FROM DUAL;
ROLLBACK;

That behaviour has nothing to do with Java though.
You can do wrong stuff in any language. Actually it looks more like a C program because of the SELECT ... INTO statement which is not possible with standard JDBC.

When using a connection pool it is quite common to configure a statement that is issued before the pool returns a cached connection to the application to make sure it is still active (it could have been "killed" by network problem, or because the server node in the cluster is no longer there, or Oracle has been restarte, ...)

To take it forward, the next step should be to view the appropriate system generated logs. If needed, you will have to reconfigure the database.

This will likely tell you the "culprit" SQL statements and you can address them separately.

I heard from one of my friends (an Oracle expert) that a way to force a commit without changing the application is to shorten the size of the rollback segment files since it will changeover to a new file automatically and the changeover automatically triggers a commit. This will of course interfere with the application in subtle ways but if it is mostly a single app (so serialised), then no noticable problems.

Another point,

Two in PowerBuilder, one is a report writer but not sure in what language.

If the reports are summaries and aggregates or looking up master tables, they are likely locking the database. You can ask the user to quit the menu and login again when needed.

I heard from one of my friends (an Oracle expert) that a way to force a commit without changing the application is to shorten the size of the rollback segment files since it will changeover to a new file automatically and the changeover automatically triggers a commit.

This sounds like a very questionable statement. Oracle will never automatically commit a transaction.
If the rollback segment (undo tablespace since Oracle 9) is too small Oracle will thrown an error.
I would be seriously concerned if Oracle did commit my transactions on its own behalf (except when running in autocommit mode)

Another point, If the reports are summaries and aggregates or looking up master tables, they are likely locking the database. You can ask the user to quit the menu and login again when needed.

SELECT statements (and that's what a report normally does), never locks anything in Oracle
(unless you specify FOR UPDATE which would be very uncommon for a report, and then it would still not lock other SELECTs)