> 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), commit tx4
>>
>> att1: update version3 (blob1), commit tx2
>>
>> Here we have chain of versions:
>>
>> version3 (tx2, blob1) -> version2 (tx4, blob2) -> version1 (tx1, blob1)
>
> I have tested it with following script:
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.
...
> As the result, content of the blob was the same, but id was different. What
> did I wrong?
Read at comments at BLB_move:
* Perform an assignment to a blob field or a blob descriptor.
* When assigning to a field, unless the blob is null,
* this requires that either a temporary blob be materialized or that
* a permanent blob be copied.
You assigned variable to a field, it leads to the copying of blob contents.
And this is correct action.
Regards,
Vlad
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
