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

[Dale Henrichs via Glass]

Well, you are right that without details it is nearly impossible to 
guess ... [as Richard mentions, `Obect _objectForOop: 9749490177` is 
your best clue]

You don't mention if there is any other activity in the system?

A commit conflict implies that there is at least one other gem doing 
work of some kind so presumably the single commit took long enough for 
another gem to modify an object in common (the object with oop 
9749490177) ...

So if the object itself doesn't give you a big enough clue, you should 
think about the activity that might be going on in other gems ...

Dale


On 02/22/2017 01:23 PM, Marten Feldtmann via Glass 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/dea3a1fd/attachment.html>