At 12:37 PM 6/10/2003 +0530, you wrote:

>Well,
>I am not an expert and would like somebody who knows more about FB to
>validate this.
>
>If you are in an environment where you are opening a dataset and
>displaying to the user using some bound controls and the user is likely to
>hold this screen open for some time it is not enough if you set the
>transaction as a read only transaction.

Showing data to the users in a read-only transaction won't hold up the
OAT. It should be ReadCommitted and any datasets in it will need to be
refreshed to get an updated view. No need to commit that transaction though.

If you want an updatable dataset, you will have to have a read-write
transaction. That's the one that shouldn't hang around in an uncommitted
state, or be kept constantly rolling over with CommitRetaining.

>If a transaction is set to read only and you open a dataset and keep it
>open for some time the OAT will get stuck and cause performance problems
>if many users are connected your database. To keep that OAT moving you
>will need to refresh this transaction once in a way.

You're confused here.

>However if your transaction isolation is set to read-committed then the
>OAT will not get stuck and you dont need to worry about refreshing your
>dataset.

It's not the transaction isolation that causes the OAT to get stuck. It's
having read-write transactions that don't get committed, or that use
CommitRetaining. If you have your read-write transactions in AutoCommit
mode, you are getting CommitRetaining, not hard Commits.

>Well I am not very sure what are the other implications of setting the
>transaction isolation to read-committed in your application but in my
>application this work fine

It should work fine - but isolation readcommitted doesn't solve the problem
of stuck OAT.

Helen