e.g.
- Select value from two dynamic source, add them and write back.
- a generic or a very dynamic code (EXECUTE STATEMENT) currenly have to
store values in VARCHAR variables, because in other case (variable
defined for every data type) the code would be VERY ugly. And because of
this VARCHAR
11.05.2014 10:44, Vlad Khorsun wrote:
It is better to write application to test it. And application should be
clever enough
to be able to put already read blob_id into parameter instead of creating new
blob_id.
I tested with attached application and got this:
tx1: blob id = 80:1
tx2: bl
> 11.05.2014 0:18, Vlad Khorsun wrote:
>> It is wrong for "lost update" scenario, which is allowed for
>> read-committed transactions:
>>
>> att1: start tx1, insert version1 (blob1), commit tx1
>>
>> att1: start tx2 (read-committed), read version1 (blob1)
>>
>> att2: start tx4, update version
11.05.2014 0:18, Vlad Khorsun wrote:
> It is wrong for "lost update" scenario, which is allowed for
> read-committed transactions:
>
> att1: start tx1, insert version1 (blob1), commit tx1
>
> att1: start tx2 (read-committed), read version1 (blob1)
>
> att2: start tx4, update version2 (blob2),
There may be more problems, who knows. Changing a 30 years old behavior is
guaranteed to produce surprises.
;-)
Claudio.
> -Original Message-
> From: Simonov Denis [mailto:sim-m...@list.ru]
> Sent: Domingo, 11 de Mayo de 2014 1:46
>
> Thank you Claudio. Build 3.0.0.31129 works without e
> is your scenario even possible?
>
> wouldn't the engine report an update collision when update version3 was
> attempted?
Since tx2 is read-committed and tx4 is already committed - yes, it is
possible.
Regards,
Vlad
---
