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

[Richard Sargent via Glass]

Marten,

I think 9749490177 is the oop of the object with the conflict. You should
look up the object (e.g. Object _objectForOop:974949017). Whatever that
object is, it will be informative for diagnosing the problem.


In general, it's a good guideline to keep your transactions down to a
reasonable size when possible. Of course, there *is* merit in an "all or
nothing" approach with a single transaction.


On Wed, Feb 22, 2017 at 1: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170222/f0ae02d0/attachment.html>