Subject | Re: [ib-support] wait transactions and rollback |
---|---|
Author | Woody |
Post date | 2002-06-25T16:08:17Z |
From: "Danny Garcia Hernandez" <danny@...>
transaction does, whether it commits or rolls back. If it commits, then your
transaction will need to re-read the data to get the changes before trying
to commit itself. If the first one rolls back it's changes, then the second
one can go through without problems.
someone else has modified (or is modifying) the data you are trying to work
with. You can then decide whether to try again or go and do something else.
there are other sources that better explain them. I believe that IBPhoenix
has some good explanations for transactions, but I don't have a link, sorry.
Someone else might, though.
a field of a table when you are working with the counter to let other's know
it is in use. When the field is cleared, the next user can then proceed.
Either way, you are going to have to modify some code somewhere.
Woody (TMW)
> Hi Woody:5.6
>
> I really impressed with your comment, reading inside Interbase Api Guide
> I found thatThis is saying that the wait transaction simply waits to see what the first
>
> isc_tpb_wait : Lock resolution specified that the transaction is to wait
> until locked resources are released before retrying an operation.
transaction does, whether it commits or rolls back. If it commits, then your
transaction will need to re-read the data to get the changes before trying
to commit itself. If the first one rolls back it's changes, then the second
one can go through without problems.
> isc_tpb_no_wait: Lock resolution specifies that the transation is not waitExactly. This allows you to immediatly display a message to the user that
> for locks to be released, but instead, a lock conflict error should be
> returned immediately
someone else has modified (or is modifying) the data you are trying to work
with. You can then decide whether to try again or go and do something else.
> The books is talking about wait transaction different as you are saying,you
> say that de wait trasaction wait for the first commit, but not to retrythe
> action else to return the error?I don't think the manuals are very clear for beginners to transactions, but
there are other sources that better explain them. I believe that IBPhoenix
has some good explanations for transactions, but I don't have a link, sorry.
Someone else might, though.
> I´m really confused!!!!Ah, a true believer!!! Welcome to the club of the unknown. <G>
> The solutions of our problem with counter look like your loop examples.But,
> there is not posible transactional solution without modify database code?.Not that I'm aware of. The only other thing I could think of would be to set
a field of a table when you are working with the counter to let other's know
it is in use. When the field is cleared, the next user can then proceed.
Either way, you are going to have to modify some code somewhere.
Woody (TMW)