[Glass] Strange behaviour ... too many data and commit failed not due to memory, but conflicts

[Mariano Martinez Peck via Glass]

On Wed, Feb 22, 2017 at 7:09 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

> Did you try inspecting (Object _objectForOpp: 9749490177) to see which
> was the conflict?
>
>
Sorry, I was offline and the email was sent automatically (didn't see Dale
and Richard answers)


> On Wed, Feb 22, 2017 at 6:23 PM, Marten Feldtmann via Glass <
> glass at lists.gemtalksystems.com> wrote:
>
>> Today I noticed a behaviour I found strange. In one of our project we had
>> to import address data and my general test case was around100000 addresses
>> and the import into Gemstone/S went without problems (using ONE
>> transaction) - it was a single task (no other applications running agsint
>> the database). It never failed. It simply worked.
>>
>> Now I talked with a customer and he told me about projects with 300.000
>> addresses and additional columns (etc). Much more data ...
>>
>> Ok, I build a test case data set and to my surprise: Gemstone/S was NEVER
>> able to import that data set in ONE transaction. The commit ALWAYS failed.
>> The commit failed but not due to memory problems, but due to conflict
>> problems ! Again no other task was running against this database (all the
>> other REST topaz scripts had nothing to do).
>>
>> Then I wanted to know, why the commit always failed and I managed to get
>> this output:
>>
>> failureRead-Write Conflicts...
>>
>> Write-Write Conflicts...    9749490177
>>
>> Write-Dependency Conflicts...
>>
>> Write-ReadLock Conflicts...
>>
>> Write-WriteLock Conflicts...
>>
>> Rc-Write-Write Conflicts...
>>
>> Synchronized-Commit Conflicts...
>>
>> When I import the same data - but doing a commit after e.g. 50000
>> addresses, the import is again stable as usual. The test cases uses lots of
>> RcCounter instances (and those values are changed with each address) - but
>> other like that I see no unusual stuff.
>>
>>
>> I know, I know - no real solid information, but this behaviour seemed
>> strange to me ...
>>
>>
>> But perhaps someone has a hint ????
>>
>>
>>
>> Marten
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170222/5878ef38/attachment.html>