Thank you for your explanation Vlad, the proccess is more clear for me now.
Greatings.
Walter.
On Mon, Dec 29, 2014 at 4:55 AM, hv...@users.sourceforge.net
[firebird-support] wrote:
>
>
> Walter,
>
> there are few reasons:
>
> a) MVCC engine never block records - it just can't :)
>
> b) the o
Walter,
there are few reasons:
a) MVCC engine never block records - it just can't :)
b) the only way to disable concurrent updates of the same record is... update
:)
More exactly: engine must mark primary record version by current transaction
and
it will make concurrent writes wait or fail.
No need to apologize Walter. Thanks for trying to help me out! :)
Regards.
Yes, you are right.
I had a misconcept. Sorry.
Greetings.
Walter.
On Thu, Dec 25, 2014 at 12:00 PM, Walter R. Ojeda Valiente <
sistemas2000profesio...@gmail.com> wrote:
> Strange, I will test it, too. Maybe I have a misconcept.
>
> Greetings.
>
> Walter.
>
>
> On Thu, Dec 25, 2014 at 11:36 AM
Strange, I will test it, too. Maybe I have a misconcept.
Greetings.
Walter.
On Thu, Dec 25, 2014 at 11:36 AM, brucedickin...@wp.pl [firebird-support] <
firebird-support@yahoogroups.com> wrote:
>
>
> Walter,
>
> I've tested what you've said. But it does not matter which transactions
> blocks re
Walter,
I've tested what you've said. But it does not matter which transactions blocks
record first (older or "younger"). When I do it slowly..it works ok. But if I
start to spam those inserts with many inserts per second then I got deadlock.
Thanks Set,
unfortunately my case is exactly like I've described it above.
I like your idea, thanks for sharing it, will have it at the back of my head as
solution for other problems.
Hello Bruce
Yes, transaction T1 can block a row and transaction T2 will wait. But if
transaction T2 blocks a row then transaction T1 can not wait and dead.
Greetings.
Walter.
On Thu, Dec 25, 2014 at 7:27 AM, brucedickin...@wp.pl [firebird-support] <
firebird-support@yahoogroups.com> wrote:
>
>"The main purposes of explicit locks are (1) to prevent expensive handling of
>update conflict errors in heavily loaded application"
>
>this is the exact reason I try to avoid conflicts. My threads can wait but
>they should not raise exceptions.
>
>I always though that it is possible to avoid su
Walter,
thank you very much for trying to explain that to me. Unfortunately I've got
lost somewhere in the middle of your response...
>>- If you are updating or deleting just one row, then no conflict can happen
>>with your settings. But if you want >>to update or delete several rows then
Bruce, if I understand transactions rightly the things are the following:
- If you are updating or deleting just one row, then no conflict can happen
with your settings. But if you want to update or delete several rows then
conflicts can happens.
- Transaction T1 starts, transaction T2 starts, tr
Thank you Hugo, I was bit reluctant to use WITH LOCK since documentation
discourages its usage.
I've tried it but it did not help.
Documentation says:
"The main purposes of explicit locks are (1) to prevent expensive handling of
update conflict errors in heavily loaded application"
this is the
I see, thanks for clarification.
24.12.2014 11:22, brucedickin...@wp.pl wrote:
>
> I've set my transaction parameters like this:
>
> FtraMain.TRParams.Add('isc_tpb_write');
> FtraMain.TRParams.Add('isc_tpb_read_committed');
> FtraMain.TRParams.Add('isc_tpb_wait');
> FtraMain.TRParams.Add('isc_tpb_no_rec_version');
>
> As far as I
Just one more thing: that works as expected (no deadlock exception) when I am
not spamming updates to table. For example:
Transaction 1: Update, no commit.
Transaction 2: Update, (transaction starts waiting).
Transaction 1: Commit;
Transaction 2: (Stops waiting) Commit;
I do not understand when
15 matches
Mail list logo
