Hi Woody:

I really impressed with your comment, reading inside Interbase Api Guide 5.6
I found that

isc_tpb_wait : Lock resolution specified that the transaction is to wait
until locked resources are released before retrying an operation.

isc_tpb_no_wait: Lock resolution specifies that the transation is not wait
for locks to be released, but instead, a lock conflict error should be
returned immediately

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 retry the
action else to return the error?

I´m really confused!!!!

The solutions of our problem with counter look like your loop examples. But,
there is not posible transactional solution without modify database code?.

Thanks in advance
Danny

----- Original Message -----
From: "Woody" <woody.tmw@...>
To: <ib-support@yahoogroups.com>
Sent: Tuesday, June 25, 2002 4:36 PM
Subject: Re: [ib-support] wait transactions and rollback


> From: "Danny Garcia Hernandez" <danny@...>
> > hi helen:
> >
> > i cant understand why wait transantion cant be used, if i want a
> > trasanction wait until the first transaction commit the change, then,
> when
> > first transaction finish, last trasaction can continue the actions.
Where
> is
> > the conflict?, i dont want the last trasaction comeback and show a
message
> > to the user saying "the record is using, retry later".
>
> That's not quite how wait transactions work. If the first user commits
> his/her changes, then the second user will still get an error, it just
waits
> until the commit to do so. If the first user rolls back their changes,
then
> the second one will go through since nothing really changed.
>
> >
> > Can you help me to undestand?. Maybe my problems is in the way to
> implement
> > the counters.
> >
> > I think too that generator is not a good option because the counters
would
> > be consecutive
> > 1,2,3,4,5.
>
> If you switch to no-wait transactions, the error will be returned right
away
> and you can handle it in a loop that keeps trying until it succeeds. In
most
> cases, this will be a very short time period if it happens at all. You
could
> even put a counter in the loop that let's the user know the counter is
> locked by another user after 10 tries (or something like that) and asks if
> they want to continue trying or give up and try again later.
>
> HTH
> Woody (TMW)
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>