Subject | Re: Re: Re: [IBO] Transaction->ReadOnly = true |
---|---|
Author | GOVINDKRISHNA |
Post date | 2003-10-06T09:26:38Z |
Helen,
Thanks for the clarifications.
gk
------------------Original Message-----------
From : Helen Borrie <helebor@...>
To : IBObjects@yahoogroups.com
Date : 06/10/2003 1:25:06 PM
Subject : Re: Re: [IBO] Transaction->ReadOnly = true
At 12:37 PM 6/10/2003 +0530, you wrote:
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.
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.
of stuck OAT.
Helen
___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Thanks for the clarifications.
gk
------------------Original Message-----------
From : Helen Borrie <helebor@...>
To : IBObjects@yahoogroups.com
Date : 06/10/2003 1:25:06 PM
Subject : Re: Re: [IBO] Transaction->ReadOnly = true
At 12:37 PM 6/10/2003 +0530, you wrote:
>Well,Showing data to the users in a read-only transaction won't hold up the
>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.
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 itYou're confused here.
>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.
>However if your transaction isolation is set to read-committed then theIt's not the transaction isolation that causes the OAT to get stuck. It's
>OAT will not get stuck and you dont need to worry about refreshing your
>dataset.
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 theIt should work fine - but isolation readcommitted doesn't solve the problem
>transaction isolation to read-committed in your application but in my
>application this work fine
of stuck OAT.
Helen
___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>>>This mail is created in Hamsa. www.jlmatrix.com <<<